Amazon CodeCatalyst는 더 이상 신규 고객에게 공개되지 않습니다. 기존 고객은 정상적으로 서비스를 계속 이용할 수 있습니다. 자세한 내용은 [CodeCatalyst에서 마이그레이션하는 방법](migration.md) 단원을 참조하십시오.
기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 워크플로 YAML 정의
다음은 워크플로 정의 파일의 참조 설명서입니다.
*워크플로 정의 파일*은 워크플로를 설명하는 YAML 파일입니다. 기본적으로 파일은 [소스 리포지토리](source-repositories.md)의 루트에 있는 `~/.codecatalyst/workflows/` 폴더에 저장됩니다. 파일은 확장자가 .yml 또는 .yaml일 수 있으며 확장자는 소문자여야 합니다.
워크플로 정의 파일을 생성하고 편집하기 위해 vim과 같은 편집기를 사용하거나, CodeCatalyst 콘솔의 시각적 편집기 또는 YAML 편집기를 사용할 수 있습니다. 자세한 내용은 [CodeCatalyst 콘솔의 시각적 및 YAML 편집기 사용](workflow.md#workflow.editors) 섹션을 참조하세요.
**참고**
이어지는 대부분의 YAML 속성에는 시각적 편집기에 해당 UI 요소가 있습니다. UI 요소를 찾으려면 **Ctrl\$1F**를 사용합니다. 요소가 연결된 YAML 속성과 함께 나열됩니다.
**Topics**
+ [워크플로 정의 파일의 예시](#workflow.anatomy)
+ [구문 지침 및 규칙](#workflow.terms.syntax.conv)
+ [최상위 속성](#workflow.top.level)
## 워크플로 정의 파일의 예시
다음은 간단한 워크플로 정의 파일의 예시입니다. 여기에는 몇 가지 최상위 속성, `Triggers` 섹션, `Build` 및 `Test`의 두 가지 작업이 있는 `Actions` 섹션이 포함됩니다. 자세한 내용은 [워크플로 정의 파일 정보](workflow.md#workflow.example) 섹션을 참조하세요.
```
Name: MyWorkflow
SchemaVersion: 1.0
RunMode: QUEUED
Triggers:
- Type: PUSH
Branches:
- main
Actions:
Build:
Identifier: aws/build@v1
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: docker build -t MyApp:latest .
Test:
Identifier: aws/managed-test@v1
DependsOn:
- Build
Inputs:
Sources:
- WorkflowSource
Configuration:
Steps:
- Run: npm install
- Run: npm run test
```
## 구문 지침 및 규칙
이 섹션에서는 워크플로 정의 파일의 구문 규칙과 이 참조 설명서에 사용된 이름 지정 규칙에 대해 설명합니다.
### YAML 구문 지침
워크플로 정의 파일은 YAML로 작성되고 [YAML 1.1 사양](https://yaml.org/spec/)을 따르므로 해당 사양에서 허용되는 모든 항목도 워크플로 YAML에서 허용됩니다. YAML을 처음 사용하는 경우 유효한 YAML 코드를 제공하기 위한 몇 가지 간단한 지침이 있습니다.
+ **대/소문자 구분**: 워크플로 정의 파일은 대/소문자를 구분하므로 이 설명서에 표시된 케이싱을 사용해야 합니다.
+ **특수 문자**: `{`, `}` , `[` , `]` , &, `*` , `#` , `?` , `|` , `-` , < , >, `=` , `!` , `%` , `@` , `:` , ``` ,`,` 등의 특수 문자가 포함된 속성 값을 따옴표 또는 큰따옴표로 묶어 사용하는 것이 좋습니다.
따옴표를 포함하지 않으면 이전에 나열된 특수 문자가 예상치 못한 방식으로 해석될 수 있습니다.
+ **속성 이름**: 속성 *names*(속성 *values*가 아님)은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 따옴표나 큰따옴표를 사용하여 속성 이름에 특수 문자와 공백을 사용할 수 없습니다.
허용되지 않음:
`'My#Build@action'`
`My#Build@action`
`My Build Action`
허용:
`My-Build-Action_1`
+ **이스케이프 코드**: 속성 값에 이스케이프 코드(예: `\n` 또는 `\t`)가 포함된 경우 다음 지침을 따릅니다.
+ 작은따옴표를 사용하여 이스케이프 코드를 문자열로 반환합니다. 예를 들어, `'my string \n my string'`, `my string \n my string` 문자열을 분환합니다.
+ 큰따옴표를 사용하여 이스케이프 코드를 구문 분석합니다. 예를 들어, `"my string \n my new line"`는 다음을 반환합니다.
```
my string
my new line
```
+ **설명**: `#`를 사용한 서문 설명입니다.
예제:
```
Name: MyWorkflow
# This is a comment.
SchemaVersion: 1.0
```
+ **트리플 대시(`---`)**: YAML 코드에 `---`를 사용하지 마세요. CodeCatalyst는 `---` 이후의 모든 항목을 무시합니다.
### 이름 지정 규칙
이 가이드에서는 *속성* 및 *섹션*이라는 용어를 사용하여 워크플로 정의 파일의 주요 항목을 참조합니다.
+ *속성*은 콜론(`:`)을 포함하는 모든 항목입니다. 예를 들어, 다음 코드 조각에서 `Name`, `SchemaVersion`, `RunMode`, `Type`, `Triggers` 및 `Branches` 속성은 모두 입니다.
+ *섹션*은 하위 속성이 있는 모든 속성입니다. 다음 코드 조각에는 `Triggers` 섹션이 하나 있습니다.
**참고**
이 가이드에서는 컨텍스트에 따라 '섹션'을 '속성'이라고 하며 그 반대로 볼 수 있습니다.
```
Name: MyWorkflow
SchemaVersion: 1.0
RunMode: QUEUED
Triggers:
- Type: PUSH
Branches:
- main
```
## 최상위 속성
다음은 워크플로 정의 파일의 최상위 속성에 대한 참조 설명서입니다.
```
# Name
Name: workflow-name
# Schema version
SchemaVersion: 1.0
# Run mode
RunMode: QUEUED|SUPERSEDED|PARALLEL
# Compute
Compute:
...
# Triggers
Triggers:
...
# Actions
Actions:
...
```
### Name
(필수)
워크플로의 이름입니다. 워크플로 이름은 워크플로 목록에 표시되고 알림 및 로그에 언급됩니다. 워크플로 이름과 워크플로 정의 파일 이름이 일치하거나 이름을 다르게 지정할 수 있습니다. 워크플로 이름은 고유하지 않아도 됩니다. 워크플로 이름은 영숫자 문자(a-z, A-Z, 0-9), 하이픈(-) 및 밑줄(\$1)로 제한됩니다. 스페이스은 허용되지 않습니다. 워크플로 이름에서 특수 문자와 공백을 활성화하는 데 따옴표를 사용할 수 없습니다.
해당 UI: 시각적 편집기/워크플로 속성/**워크플로 이름**
### SchemaVersion
(필수)
워크플로 정의의 스키마 버전입니다. 현재 유일한 유효 값은 `1.0`입니다.
해당 UI: *없음*
### RunMode
(선택 사항)
CodeCatalyst가 여러 실행을 처리하는 방법. 다음 값 중 하나를 사용할 수 있습니다.
+ `QUEUED` - 여러 실행이 대기 중이고 하나씩 실행됩니다. 대기열에서 최대 50회까지 실행할 수 있습니다.
+ `SUPERSEDED` - 여러 실행이 대기 중이고 하나씩 실행됩니다. 대기열은 한 번만 실행할 수 있으므로 두 개의 실행이 같은 대기열에서 동시에 종료되면, 나중에 실행된 것이 먼저 실행된 것을 대체(인계)하고, 먼저 실행된 것은 취소됩니다.
+ `PARALLEL` – 여러 번 동시에 실행됩니다.
생략 시 기본값은 `QUEUED`입니다.
자세한 내용은 [실행의 대기열 동작 구성](workflows-configure-runs.md) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 속성/고급/**실행 모드**
### Compute
(선택 사항)
워크플로 작업을 실행하는 데 사용되는 컴퓨팅 엔진입니다. 워크플로 수준 또는 작업 수준에서 컴퓨팅을 지정할 수 있지만 둘 다 지정할 수는 없습니다. 워크플로 수준에서 지정하면 컴퓨팅 구성이 워크플로에 정의된 모든 작업에 적용됩니다. 워크플로 수준에서는 동일한 인스턴스에서 여러 작업을 실행할 수도 있습니다. 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
컴퓨팅에 대한 자세한 내용은 [컴퓨팅 및 런타임 이미지 구성](workflows-working-compute.md) 섹션을 참조하세요.
해당 UI: *없음*
```
Name: MyWorkflow
SchemaVersion: 1.0
...
Compute:
Type: EC2 | Lambda
Fleet: fleet-name
SharedInstance: true | false
```
#### Type
(Compute/**Type**)
(`Compute`로 설정된 경우 필수)
컴퓨팅 엔진의 유형입니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **EC2**(시각 편집기) 또는 `EC2`(YAML 편집기)
작업 실행 중 유연성을 위해 최적화되었습니다.
+ **Lambda**(시각 편집기) 또는 `Lambda`(YAML 편집기)
작업 시작 속도를 최적화했습니다.
컴퓨팅 유형에 대한 자세한 정보는 [컴퓨팅 유형](workflows-working-compute.md#compute.types)을 참고하세요.
해당 UI: 시각적 편집기/워크플로 속성/고급/**컴퓨팅 유형**
#### Fleet
(Compute/**Fleet**)
(선택 사항)
워크플로 또는 워크플로 작업을 실행할 시스템 또는 플릿을 지정합니다. 온디맨드 플릿의 경우 작업이 시작되면 워크플로가 필요한 리소스를 프로비저닝하고 작업이 완료되면 시스템이 파괴됩니다. 온디맨드 플릿의 예시: `Linux.x86-64.Large`, `Linux.x86-64.XLarge`. 온디맨드 플릿에 대한 자세한 내용은 [온디맨드 플릿 속성](workflows-working-compute.md#compute.on-demand) 섹션을 참조하세요.
프로비저닝된 플릿을 사용하면 워크플로 작업을 실행하도록 전용 시스템 세트를 구성할 수 있습니다. 이러한 시스템은 유휴 상태로 유지되므로 작업을 즉시 처리할 수 있습니다. 프로비저닝된 플릿에 대한 자세한 내용은 [프로비저닝된 플릿 속성](workflows-working-compute.md#compute.provisioned-fleets) 섹션을 참조하세요.
`Fleet` 생략 시 기본값은 `Linux.x86-64.Large`입니다.
컴퓨팅 플릿에 대한 자세한 내용은 [컴퓨팅 플릿](workflows-working-compute.md#compute.fleets) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 속성/고급/**컴퓨팅 플릿**
#### SharedInstance
(Compute/**SharedInstance**)
(선택 사항)
작업에 대한 컴퓨팅 공유 기능을 지정합니다. 컴퓨팅 공유를 사용하면 워크플로의 작업이 동일한 인스턴스(런타임 환경 이미지)에서 실행됩니다. 다음 값 중 하나를 사용할 수 있습니다.
+ `TRUE`는 런타임 환경 이미지가 워크플로 작업 간에 공유됨을 의미합니다.
+ `FALSE`는 워크플로의 각 작업에 대해 별도의 런타임 환경 이미지가 시작되고 사용되므로 추가 구성 없이 아티팩트 및 변수와 같은 리소스를 공유할 수 없음을 의미합니다.
컴퓨팅 공유에 대한 자세한 내용은 [작업 간에 컴퓨팅 공유](compute-sharing.md) 섹션을 참조하세요.
해당 UI: *없음*
### Triggers
(선택 사항)
이 워크플로를 위한 하나 이상의 트리거의 순서입니다. 트리거가 지정되지 않은 경우, 수동으로 워크플로를 시작해야 합니다.
트리거에 대한 자세한 내용은 [트리거를 사용하여 워크플로 실행 자동 시작](workflows-add-trigger.md) 주제를 참조하세요.
해당 UI: 시각적 편집기/워크플로 다이어그램/**트리거**
```
Name: MyWorkflow
SchemaVersion: 1.0
...
Triggers:
- Type: PUSH
Branches:
- branch-name
FilesChanged:
- folder1/file
- folder2/
- Type: PULLREQUEST
Events:
- OPEN
- CLOSED
- REVISION
Branches:
- branch-name
FilesChanged:
- file1.txt
- Type: SCHEDULE
# Run the workflow at 10:15 am (UTC+0) every Saturday
Expression: "15 10 ? * 7 *"
Branches:
- branch-name
```
#### Type
(Triggers/**Type**)
(`Triggers`로 설정된 경우 필수)
트리거 유형을 지정합니다. 다음 값 중 하나를 사용할 수 있습니다.
+ **푸시**(시각적 편집기) 또는 `PUSH`(YAML 편집기)
푸시 트리거는 변경 사항이 소스 리포지토리로 푸시될 때 워크플로 실행을 시작합니다. 워크플로 실행은 푸시 *대상* 브랜치(즉, 대상 브랜치)의 파일을 사용합니다.
+ **풀 요청**(시각적 편집기) 또는 `PULLREQUEST`(YAML 편집기)
풀 요청 트리거는 소스 리포지토리에서 풀 요청이 열리거나 업데이트되거나 닫힐 때 워크플로 실행을 시작합니다. 워크플로 실행은 *가져오려는* 브랜치(즉, 소스 브랜치)의 파일을 사용합니다.
+ **일정**(시각적 편집기) 또는 `SCHEDULE`(YAML 편집기)
일정 트리거는 지정한 cron 표현식으로 정의된 일정에 따라 워크플로를 실행합니다. 브랜치 파일을 사용하여 소스 리포지토리의 각 브랜치에 대해 별도의 워크플로 실행이 시작됩니다. (트리거가 활성화되는 브랜치를 제한하려면 **브랜치** 필드(시각적 편집기) 또는 `Branches` 속성(YAML 편집기)을 사용합니다.)
일정 트리거를 구성할 때는 다음 지침을 따르세요.
+ 워크플로당 하나의 일정 트리거만 사용합니다.
+ CodeCatalyst 스페이스에 여러 워크플로를 정의한 경우 동시에 시작하도록 10개 이하로 예약하는 것이 좋습니다.
+ 실행 사이에 충분한 시간을 두고 트리거의 cron 표현식을 구성해야 합니다. 자세한 내용은 [Expression](#workflow.triggers.expression) 섹션을 참조하세요.
예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 다이어그램/트리거/**트리거 유형**
#### Events
(Triggers/**Events**)
(`Type` 트리거가 `PULLREQUEST`로 설정된 경우 필수)
워크플로 실행을 시작할 풀 요청 이벤트의 유형을 지정합니다. 유효한 값은 다음과 같습니다.
+ **풀 요청이 생성됨**(시각적 편집기) 또는 `OPEN`(YAML 편집기)
풀 요청이 생성되면 워크플로 실행이 시작됩니다.
+ **풀 요청이 닫힘**(시각적 편집기) 또는 `CLOSED`(YAML 편집기)
풀 요청이 종료되면 워크플로 실행이 시작됩니다. `CLOSED` 이벤트의 동작은 까다롭고 예시를 통해 가장 잘 이해됩니다. 자세한 정보는 [예시: 풀, 브랜치 및 'CLOSED' 이벤트가 있는 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-pull-close)을 참조하세요.
+ **풀 요청에 대한 새 개정**(시각적 편집기) 또는 `REVISION`(YAML 편집기)
워크플로 실행은 풀 요청에 대한 개정이 생성될 때 시작됩니다. 풀 요청이 생성되면 첫 번째 개정이 생성됩니다. 그런 다음 풀 요청에 지정된 소스 브랜치에 새 커밋을 푸시할 때마다 새 개정이 생성됩니다. 풀 요청 트리거에 `REVISION` 이벤트를 포함하는 경우 `REVISION`는 `OPEN`의 수퍼 세트이므로 `OPEN` 이벤트를 생략할 수 있습니다.
동일한 풀 요청 트리거에서 여러 이벤트를 지정할 수 있습니다.
예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 다이어그램/트리거/**풀 요청을 위한 이벤트**
#### Branches
(Triggers/**Branches**)
(선택 사항)
워크플로 실행을 시작할 시기를 알기 위해 트리거가 모니터링하는 소스 리포지토리의 브랜치를 지정합니다. 정규식 패턴을 사용하여 브랜치 이름을 정의할 수 있습니다. 예를 들어 `main.*`을 사용하여 `main`으로 시작하는 모든 브랜치를 일치시킵니다.
지정할 브랜치는 트리거 유형에 따라 다릅니다.
+ 푸시 트리거의 경우 푸시 *대상* 브랜치, 즉 *대상* 브랜치를 지정합니다. 일치하는 브랜치의 파일을 사용하여 일치하는 브랜치당 하나의 워크플로 실행이 시작됩니다.
예시: `main.*`, `mainline`
+ 풀 요청의 경우 *푸시할* 브랜치, 즉 *대상* 브랜치를 지정합니다. 워크플로 정의 파일과 소스 브랜치(일치하는 브랜치 *아님*)의 **소스** 파일을 사용하여 일치하는 브랜치당 하나의 워크플로 실행이 시작됩니다.
예시: `main.*`, `mainline`, `v1\-.*`(`v1-`로 시작하는 브랜치와 일치)
+ 일정 트리거의 경우 예약된 실행에서 사용할 파일이 포함된 브랜치를 지정합니다. 워크플로 정의 파일과 일치하는 브랜치의 소스 파일을 사용하여 일치하는 브랜치당 하나의 워크플로 실행이 시작됩니다.
예시: `main.*`, `version\-1\.0`
**참고**
브랜치를 지정하지 *않으면* 트리거는 소스 리포지토리의 모든 브랜치를 모니터링하고 다음에서 워크플로 정의 파일 및 소스 파일을 사용하여 워크플로 실행을 시작합니다.
푸시 *대상* 브랜치(푸시 트리거용). 자세한 내용은 [예시: 간단한 코드 푸시 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-push-simple) 섹션을 참조하세요.
풀 *원본* 브랜치(풀 요청 트리거용). 자세한 내용은 [예시: 간단한 풀 요청 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-pull-simple) 섹션을 참조하세요.
모든 브랜치(일정 트리거용). 소스 리포지토리의 브랜치당 워크플로 실행이 한 번 시작됩니다. 자세한 내용은 [예시: 간단한 일정 트리거](workflows-add-trigger-examples.md#workflows-add-trigger-examples-schedule-simple) 섹션을 참조하세요.
브랜치 및 트리거에 대한 자세한 내용은 [트리거 및 브랜치 사용 지침](workflows-add-trigger-considerations.md) 섹션을 참조하세요.
더 많은 예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md)를 참조합니다.
해당 UI: 시각 편집기/워크플로 다이어그램/트리거/**브랜치**
#### FilesChanged
(Triggers/**FilesChanged**)
(`Type` 트리거가 `PUSH` 또는 `PULLREQUEST`로 설정된 경우 선택 사항. `Type` 트리거가 `SCHEDULE`로 설정된 경우에는 지원되지 않음)
워크플로 실행을 시작해야 하는 시기를 알 수 있도록 트리거가 모니터링하는 소스 리포지토리의 파일 또는 폴더를 지정합니다. 정규식을 사용하여 파일 이름 또는 경로와 일치시킬 수 있습니다.
예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 다이어그램/트리거/**파일 변경됨**
#### Expression
(Triggers/**Expression**)
(`Type` 트리거가 `SCHEDULE`로 설정된 경우 필수)
예약된 워크플로 실행 시기를 설명하는 cron 표현식을 지정합니다.
CodeCatalyst의 Cron 표현식은 다음과 같은 6개 필드 구문을 사용합니다. 여기서 각 필드는 공백으로 구분됩니다.
*minutes* *hours* *days-of-month* *month* *days-of-week* *year*
**cron 표현식의 예**
| 분 | 시간 | 일 | 월 | 요일 | 연도 | 의미 |
| --- | --- | --- | --- | --- | --- | --- |
| 0 | 0 | ? | \$1 | 월-금 | \$1 | 매주 월요일부터 금요일까지 자정(UTC\$10)에 워크플로를 실행합니다. |
| 0 | 2 | \$1 | \$1 | ? | \$1 | 매일 오전 2시(UTC\$10)에 워크플로를 실행합니다. |
| 15 | 22 | \$1 | \$1 | ? | \$1 | 매일 오후 10:15(UTC\$10)에 워크플로를 실행합니다. |
| 0/30 | 22-2 | ? | \$1 | 토-일 | \$1 | 시작일 오후 10시부터 다음 날 오전 2시(UTC\$10) 사이에 토요일부터 일요일까지 30분마다 워크플로를 실행합니다. |
| 45 | 13 | L | \$1 | ? | 2023-2027 | 2023년부터 2027년까지 매월 마지막 날 오후 1시 45분(UTC\$10)에 워크플로를 실행합니다. |
CodeCatalyst에서 cron 표현식을 지정할 때는 다음 지침을 따라야 합니다.
+ `SCHEDULE` 트리거당 단일 cron 표현식을 지정합니다.
+ YAML 편집기에서 cron 표현식을 큰따옴표(`"`)로 묶습니다.
+ 시간은 협정 세계시(UTC)로 지정합니다. 다른 시간대는 지원되지 않습니다.
+ 실행 간격은 최소 30분으로 구성합니다. 더 빠른 주기는 지원되지 않습니다.
+ *days-of-month* 또는 *days-of-week* 필드를 지정하되 둘 다 지정하지는 않습니다. 필드 중 하나에 값 또는 별표(`*`)를 지정하는 경우 다른 필드에는 물음표(`?`)를 사용해야 합니다. 별표는 '모두'를 의미하고 물음표는 '모두'를 의미합니다.
cron 표현식의 더 많은 예시와 `?`, `*`, `L`과 같은 와일드카드에 대한 정보는 *Amazon EventBridge 사용 설명서*의 [cron 표현식 참조](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cron-expressions.html)를 참조하세요. EventBridge 및 CodeCatalyst의 Cron 표현식은 정확히 동일한 방식으로 작동합니다.
일정 트리거의 예시는 [예시: 워크플로의 트리거](workflows-add-trigger-examples.md) 섹션을 참조하세요.
해당 UI: 시각적 편집기/워크플로 다이어그램/트리거/**일정**
### 작업
이 워크플로에 대한 하나 이상의 작업 시퀀스입니다. CodeCatalyst는 다양한 유형의 기능을 제공하는 빌드 및 테스트 작업과 같은 여러 작업 유형을 지원합니다. 각 작업 유형에는 다음이 포함됩니다.
+ 작업의 고유 하드 코딩 ID를 나타내는 `Identifier` 속성입니다. 예를 들어 `aws/build@v1`은 빌드 작업을 식별합니다.
+ 작업과 관련된 속성이 포함된 `Configuration` 섹션입니다.
각 작업 유형에 대한 자세한 내용은 [작업 유형](workflows-actions.md#workflows-actions-types) 항목을 참조하세요. [작업 유형](workflows-actions.md#workflows-actions-types) 주제에는 각 작업에 대한 설명서 링크가 있습니다.
다음은 워크플로 정의 파일의 작업 및 작업 그룹에 대한 YAML 참조입니다.
```
Name: MyWorkflow
SchemaVersion: 1.0
...
Actions:
action-or-gate-name:
Identifier: identifier
Configuration:
...
#Action groups
action-group-name:
Actions:
...
```
#### action-or-gate-name
(Actions/*action-or-gate-name*)
(필수)
*action-name*을 작업을 수행할 이름으로 바꿉니다. 작업 이름은 워크플로 내에서 고유해야 하며 영숫자, 하이픈 및 밑줄만 포함해야 합니다. 구문 규칙에 대한 자세한 내용은 [YAML 구문 지침](#workflow.syntax.conv) 항목을 참조하세요.
제한을 포함한 작업의 이름 지정 방법에 대한 자세한 내용은 [action-or-gate-name](#workflow.actions.name) 섹션을 참조하세요.
해당 UI: 시각적 편집기/*action-name*/구성 탭/**작업 이름** 또는 **작업 표시 이름**
#### action-group-name
(Actions/*action-group-name*)
(선택 사항)
*작업 그룹*에는 하나 이상의 작업이 포함됩니다. 작업을 작업 그룹으로 그룹화하면 워크플로를 체계적으로 관리할 수 있고, 서로 다른 그룹 간의 종속성을 구성할 수도 있습니다.
*action-group-name*을 작업 그룹에 부여하려는 이름으로 바꿉니다. 작업 그룹 이름은 워크플로 내에서 고유해야 하며 영숫자, 하이픈 및 밑줄만 포함해야 합니다. 구문 규칙에 대한 자세한 내용은 [YAML 구문 지침](#workflow.syntax.conv) 항목을 참조하세요.
작업 그룹에 대한 자세한 내용은 [작업을 작업 그룹으로 그룹화](workflows-group-actions.md) 섹션을 참조하세요.
해당 UI: *없음*