# GitHub Actions에 대한 워크플로 구문 워크플로는 하나 이상의 작업으로 구성된 구성 가능한 자동화된 프로세스입니다. 워크플로 구성을 정의하려면 YAML 파일을 만들어야 합니다. ## 워크플로에 대한 YAML 구문 정보 워크플로 파일은 YAML 구문을 사용하며 파일 확장명이 `.yml` 또는 `.yaml`이어야 합니다. YAML을 처음 사용하며 자세히 알아보려는 경우 [Y분 안에 YAML 알아보기](https://learnxinyminutes.com/docs/yaml/)를 참조하세요. 워크플로 파일을 리포지토리의 `.github/workflows` 디렉터리에 저장해야 합니다. ## `name` 워크플로의 이름입니다. GitHub은(는) 리포지토리의 "작업" 탭 아래에 워크플로의 이름을 표시합니다. `name`을 생략하면 GitHub은(는) 리포지토리의 루트를 기준으로 워크플로 파일 경로를 표시합니다. ## `run-name` 워크플로 실행의 이름은 워크플로에서 생성됩니다. GitHub 는 리포지토리의 "작업" 탭에 있는 워크플로 실행 목록에 워크플로 실행 이름을 표시합니다. 생략되거나 공백만 있는 경우 `run-name` 실행 이름은 워크플로 실행에 대한 이벤트별 정보로 설정됩니다. 예를 들어 이벤트 또는 `push` 이벤트에 의해 `pull_request` 트리거되는 워크플로의 경우 커밋 메시지 또는 pull request 의 제목이 설정됩니다. 이 값은 식을 포함할 수 있으며 [`github`](/ko/actions/learn-github-actions/contexts#github-context) 컨텍스트와 [`inputs`](/ko/actions/learn-github-actions/contexts#inputs-context) 컨텍스트를 참조할 수 있습니다. ### ``` `run-name`의 예 ``` ```yaml run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }} ``` ## `on` 워크플로를 자동으로 트리거하려면 `on`을 사용하여 워크플로를 실행할 수 있는 이벤트를 정의합니다. 사용 가능한 이벤트 목록은 [워크플로를 트리거하는 이벤트](/ko/actions/using-workflows/events-that-trigger-workflows)을(를) 참조하세요. 워크플로를 트리거하거나 시간 일정을 설정할 수 있는 단일 또는 여러 이벤트를 정의할 수 있습니다. 특정 파일, 태그 또는 분기 변경에 대해서만 워크플로 실행이 이루어지도록 제한할 수도 있습니다. 다음 섹션에서는 이러한 방법에 대해 설명합니다. ### 단일 이벤트 사용 예를 들어 다음 `on` 값이 있는 워크플로는 워크플로 리포지토리의 분기로 푸시될 때 실행됩니다. ```yaml on: push ``` ### 여러 이벤트 사용 단일 이벤트 또는 여러 이벤트를 지정할 수 있습니다. 예를 들어 다음 `on` 값이 있는 워크플로는 워크플로 리포지토리의 분기로 푸시될 때 실행됩니다. ```yaml on: [push, fork] ``` 여러 이벤트를 지정하는 경우 워크플로를 트리거하려면 이러한 이벤트 중 하나만 발생해야 합니다. 워크플로에 대한 트리거 이벤트가 여러 개 동시에 발생하는 경우 워크플로 실행 여러 개가 트리거됩니다. ### 활동 유형 사용 일부 이벤트에는 워크플로가 실행되어야 하는 시기를 보다 정확하게 제어할 수 있는 활동 유형이 있습니다. `on..types`를 사용하여 워크플로 실행을 트리거할 이벤트 활동 유형을 정의합니다. 예를 들어 `issue_comment` 이벤트에는 `created`, `edited` 및 `deleted` 활동 유형이 있습니다. `label` 이벤트에 대해 워크플로가 트리거되면 레이블을 만들거나 편집하거나 삭제할 때마다 이 워크플로가 실행됩니다. `label` 이벤트에 대해 `created` 활동 유형을 지정하면 레이블을 편집하거나 삭제할 때가 아니라 레이블을 만들 때 워크플로가 실행됩니다. ```yaml on: label: types: - created ``` 활동 유형을 여러 개 지정한 경우 워크플로를 트리거하려면 이러한 이벤트 활동 유형 중 하나만 발생해야 합니다. 워크플로에 대한 트리거 이벤트 활동 유형 여러 개가 동시에 발생하는 경우 워크플로 실행 여러 개가 트리거됩니다. 예를 들어 다음 워크플로는 이슈가 시작되거나 레이블이 지정될 때 트리거됩니다. 레이블 두 개가 지정된 이슈가 시작되면 워크플로 실행 세 개가 시작됩니다. 하나는 이슈 시작됨 이벤트를 위한 실행이고, 두 개는 이슈에 레이블이 지정됨 이벤트 두 개를 위한 실행입니다. ```yaml on: issues: types: - opened - labeled ``` 각 이벤트 및 해당 활동 유형에 대한 자세한 내용은 [워크플로를 트리거하는 이벤트](/ko/actions/using-workflows/events-that-trigger-workflows)을(를) 참조하세요. ### 필터 사용 일부 이벤트에는 워크플로가 실행되어야 하는 시기를 더 자세히 제어할 수 있는 필터가 있습니다. 예를 들어 `push` 이벤트에는 푸시가 발생하는 경우 대신 `branches` 필터와 일치하는 분기로 푸시가 발생하는 경우에만 워크플로가 실행되도록 하는 `branches` 필터가 있습니다. ```yaml on: push: branches: - main - 'releases/**' ``` ### 여러 이벤트와 함께 활동 유형 및 필터 사용 이벤트에 대해 작업 유형 또는 필터를 지정하고 여러 이벤트에서 워크플로가 트리거되는 경우 각 이벤트를 별도로 구성해야 합니다. 구성이 없는 이벤트를 포함하여 모든 이벤트에 콜론(`:`)을 추가해야 합니다. 예를 들어 다음 `on` 값이 있는 워크플로는 다음과 같은 경우에 실행됩니다. * 레이블이 생성되는 경우 * 리포지토리의 `main` 분기에 푸시되는 경우 * GitHub Pages 사용 분기에 푸시되는 경우 ```yaml on: label: types: - created push: branches: - main page_build: ``` ## `on..types` 워크플로 실행을 트리거할 활동 유형을 정의하는 데 `on..types`을 사용합니다. 대부분의 GitHub 이벤트는 둘 이상의 활동 유형에 의해 트리거됩니다. 예를 들어 레이블이 `created`, `edited` 또는 `deleted`일 때 `label`이 트리거됩니다. `types` 키워드를 사용하면 워크플로를 실행하게 하는 작업의 범위를 좁힐 수 있습니다. 하나의 활동 유형만 웹후크 이벤트를 트리거하는 경우 `types` 키워드는 필요하지 않습니다. 이벤트 `types` 배열을 사용할 수 있습니다. 각 이벤트 및 해당 활동 유형에 대한 자세한 내용은 [워크플로를 트리거하는 이벤트](/ko/actions/using-workflows/events-that-trigger-workflows#available-events)을(를) 참조하세요. ```yaml on: label: types: [created, edited] ``` ## `on..` `pull_request` 및 `pull_request_target` 이벤트를 사용하는 경우 특정 분기를 대상으로 하는 끌어오기 요청에 대해서만 실행되도록 워크플로를 구성할 수 있습니다. 분기 이름 패턴을 포함하려는 경우 또는 분기 이름 패턴을 포함하거나 제외하려는 경우 `branches` 필터를 사용합니다. 분기 이름 패턴만 제외하려는 경우 `branches-ignore` 필터를 사용합니다. 워크플로의 동일한 이벤트에 대해 `branches` 필터와 `branches-ignore` 필터 둘 다는 사용할 수 없습니다. `branches`/`branches-ignore` 및 [`paths`/`paths-ignore`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)를 둘 다 정의하는 경우 워크플로는 두 필터가 모두 충족될 때만 실행됩니다. `branches` 및 `branches-ignore` 키워드는 `*`, `**`, `+`, `?`, `!` 및 두 개 이상의 분기 이름을 찾기 위한 기타 문자 등의 문자를 사용하는 GLOB 패턴을 허용합니다. 이름에 해당 문자가 포함되어 있고 리터럴 일치를 원하는 경우 각 특수 문자를 `\`로 이스케이프해야 합니다. glob 패턴에 대한 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)을(를) 참조하세요. ### 예: 분기 포함 `branches`에 정의된 패턴은 Git ref의 이름에 따라 평가됩니다. 예를 들어 끌어오기 요청 대상 지정을 위한 `pull_request` 이벤트가 있을 때마다 다음 워크플로가 실행됩니다. * `main`으로 명명된 분기(`refs/heads/main`) * `mona/octocat`으로 명명된 분기(`refs/heads/mona/octocat`) * `releases/10`과 같이 이름이 `releases/`로 시작하는 분기(`refs/heads/releases/10`) ```yaml on: pull_request: # Sequence of patterns matched against refs/heads branches: - main - 'mona/octocat' - 'releases/**' ``` 분기 필터링, [경로 필터링](/ko/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) 또는 [커밋 메시지](/ko/actions/managing-workflow-runs/skipping-workflow-runs)로 인해 워크플로를 건너뛰는 경우 해당 워크플로와 연결된 검사는 “보류 중” 상태로 유지됩니다. 이러한 검사가 성공해야 하는 끌어오기 요청은 병합에서 차단됩니다. ### 예: 분기 제외 패턴이 `branches-ignore` 패턴과 일치하면 워크플로가 실행되지 않습니다. `branches-ignore`에 정의된 패턴은 Git ref의 이름에 따라 평가됩니다. 예를 들어 끌어오기 요청의 대상을 지정하지 않는 한 `pull_request` 이벤트가 있을 때마다 다음 워크플로가 실행됩니다. * `mona/octocat`으로 명명된 분기(`refs/heads/mona/octocat`) * `releases/**-alpha`와 같이 이름이 `releases/beta/3-alpha`와 일치하는 분기(`refs/heads/releases/beta/3-alpha`) ```yaml on: pull_request: # Sequence of patterns matched against refs/heads branches-ignore: - 'mona/octocat' - 'releases/**-alpha' ``` ### 예: 분기 포함 및 제외 `branches` 및 `branches-ignore`를 사용하여 단일 워크플로의 동일한 이벤트를 필터링할 수 없습니다. 단일 이벤트에 대한 분기 패턴을 포함 및 제외하려면 `branches` 문자와 함께 `!` 필터를 사용하여 제외해야 하는 분기를 나타냅니다. ``` `!` 문자를 사용하여 분기를 정의하는 경우 `!` 문자 없이 하나 이상의 분기도 정의해야 합니다. 분기만 제외하려면 `branches-ignore`를 대신 사용합니다. ``` 패턴을 정의하는 순서가 중요합니다. * 긍정 일치 후 일치하는 부정 패턴(접두사 `!`)은 Git ref를 제외합니다. * 부정 일치 후 일치하는 긍정 패턴은 Git ref를 다시 포함합니다. 다음 워크플로는 `pull_request` 또는 `releases/10`를 대상으로 하는 끌어오기 요청에 대한 `releases/beta/mona` 이벤트에서 실행되지만 `releases/10-alpha` 부정 패턴이 긍정 패턴 이후에 나오므로 `releases/beta/3-alpha` 또는 `!releases/**-alpha`를 대상으로 하는 끌어오기 요청에 대해서는 그러지 않습니다. ```yaml on: pull_request: branches: - 'releases/**' - '!releases/**-alpha' ``` ## `on.push.` `push` 이벤트를 사용하는 경우 특정 분기 또는 태그에서 실행되도록 워크플로를 구성할 수 있습니다. 분기 이름 패턴을 포함하려는 경우 또는 분기 이름 패턴을 포함하거나 제외하려는 경우 `branches` 필터를 사용합니다. 분기 이름 패턴만 제외하려는 경우 `branches-ignore` 필터를 사용합니다. 워크플로의 동일한 이벤트에 대해 `branches` 필터와 `branches-ignore` 필터 둘 다는 사용할 수 없습니다. 태그 이름 패턴을 포함하려는 경우 또는 태그 이름 패턴을 포함하거나 제외하려는 경우 `tags` 필터를 사용합니다. 태그 이름 패턴만 제외하려는 경우 `tags-ignore` 필터를 사용합니다. 워크플로의 동일한 이벤트에 대해 `tags` 필터와 `tags-ignore` 필터 둘 다는 사용할 수 없습니다. `tags`/`tags-ignore`만 정의하거나 `branches`/`branches-ignore`만 정의하는 경우 정의되지 않은 Git ref에 영향을 주는 이벤트에 대해 워크플로가 실행되지 않습니다. `tags`/`tags-ignore` 또는 `branches`/`branches-ignore`를 둘 다 정의하지 않으면 분기나 태그에 영향을 주는 이벤트에 대해 워크플로가 실행됩니다. `branches`/`branches-ignore` 및 [`paths`/`paths-ignore`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)를 둘 다 정의하는 경우 워크플로는 두 필터가 모두 충족될 때만 실행됩니다. `branches`, `branches-ignore`, `tags` 및 `tags-ignore` 키워드는 두 개 이상의 분기 또는 태그 이름과 일치하도록 `*`, `**`, `+`, `?`, `!` 등의 문자를 사용하는 GLOB 패턴을 허용합니다. 이름에 해당 문자가 포함되어 있고 리터럴 일치를 원하는 경우 각 특수 문자를 `\`로 \_이스케이프\_해야 합니다. glob 패턴에 대한 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)을(를) 참조하세요. ### 예: 분기 및 태그 포함 `branches` 및 `tags`에 정의된 패턴은 Git 참조의 이름을 기준으로 평가됩니다. 예를 들어, 다음 워크플로는 `push` 이벤트가 있을 때마다 실행됩니다. * `main`으로 명명된 분기(`refs/heads/main`) * `mona/octocat`으로 명명된 분기(`refs/heads/mona/octocat`) * `releases/10`과 같이 이름이 `releases/`로 시작하는 분기(`refs/heads/releases/10`) * `v2` 태그(`refs/tags/v2`) * `v1.9.1`처럼 이름이 `v1.`으로 시작하는 태그(`refs/tags/v1.9.1`) ```yaml on: push: # Sequence of patterns matched against refs/heads branches: - main - 'mona/octocat' - 'releases/**' # Sequence of patterns matched against refs/tags tags: - v2 - v1.* ``` ### 예: 분기 및 태그 제외 패턴이 `branches-ignore` 또는 `tags-ignore` 패턴과 일치하면 워크플로가 실행되지 않습니다. `branches` 및 `tags`에 정의된 패턴은 Git 참조의 이름을 기준으로 평가됩니다. 예를 들어, `push` 이벤트가 다음을 대상으로 하지 않는 한 `push` 이벤트가 있을 때마다 다음 워크플로가 실행됩니다. * `mona/octocat`으로 명명된 분기(`refs/heads/mona/octocat`) * `releases/**-alpha`와 같이 이름이 `releases/beta/3-alpha`와 일치하는 분기(`refs/heads/releases/beta/3-alpha`) * `v2` 태그(`refs/tags/v2`) * `v1.`처럼 이름이 `v1.9`으로 시작하는 태그(`refs/tags/v1.9`) ```yaml on: push: # Sequence of patterns matched against refs/heads branches-ignore: - 'mona/octocat' - 'releases/**-alpha' # Sequence of patterns matched against refs/tags tags-ignore: - v2 - v1.* ``` ### 예: 분기 및 태그 포함 및 제외 단일 워크플로에서 동일한 이벤트를 필터링하는 데는 `branches` 및 `branches-ignore`를 사용할 수 없습니다. 마찬가지로 단일 워크플로에서 동일한 이벤트를 필터링하는 데는 `tags` 및 `tags-ignore`를 사용할 수 없습니다. 단일 이벤트에 대한 분기 또는 태그 패턴을 포함하거나 제외하려면 `branches` 또는 `tags` 필터를 `!` 문자와 함께 사용하여 제외해야 하는 분기 또는 태그를 나타냅니다. ``` `!` 문자를 사용하여 분기를 정의하는 경우 `!` 문자 없이 하나 이상의 분기도 정의해야 합니다. 분기만 제외하려면 `branches-ignore`를 대신 사용합니다. 마찬가지로 `!` 문자를 사용하여 태그를 정의하는 경우 `!` 문자 없이 하나 이상의 태그도 정의해야 합니다. 태그만 제외하려면 대신 `tags-ignore`를 사용합니다. ``` 패턴을 정의하는 순서가 중요합니다. * 긍정 일치 후 일치하는 부정 패턴(접두사 `!`)은 Git ref를 제외합니다. * 부정 일치 후 일치하는 긍정 패턴은 Git ref를 다시 포함합니다. 부정 패턴 `releases/10`는 긍정 패턴을 따르므로 다음 워크플로는 `releases/beta/mona` 또는 `releases/10-alpha`에 대한 푸시에서 실행되지만 `releases/beta/3-alpha` 또는 `!releases/**-alpha`에서는 실행되지 않습니다. ```yaml on: push: branches: - 'releases/**' - '!releases/**-alpha' ``` ## `on..` `push` 및 `pull_request` 이벤트를 사용하는 경우 변경된 파일 경로에 따라 실행되도록 워크플로를 구성할 수 있습니다. 경로 필터는 태그 푸시에 대해 평가되지 않습니다. 파일 경로 패턴을 포함하려는 경우 또는 파일 경로 패턴을 포함 및 제외하려는 경우 `paths` 필터를 사용합니다. 파일 경로 패턴만 제외하려는 경우 `paths-ignore` 필터를 사용합니다. 워크플로의 동일한 이벤트에 대해 `paths` 필터와 `paths-ignore` 필터 둘 다는 사용할 수 없습니다. 단일 이벤트에 대한 경로 패턴을 포함 및 제외하려면 접두어 `!` 문자와 함께 `paths` 필터를 사용하여 제외해야 하는 경로를 나타냅니다. > \[!NOTE] > `paths` 패턴을 정의하는 순서가 중요합니다. > > * 긍정 일치 후 일치하는 부정 패턴(접두사 `!`)은 경로를 제외합니다. > * 부정 일치 후 일치하는 긍정 패턴은 경로를 다시 포함합니다. `branches`/`branches-ignore` 및 `paths`/`paths-ignore`를 둘 다 정의하는 경우 워크플로는 두 필터가 모두 충족될 때만 실행됩니다. `paths` 및 `paths-ignore` 키워드는 둘 이상의 경로 이름에 대한 일치 판정을 위해 `*` 및 `**` 와일드카드 문자를 사용하는 GLOB 패턴을 허용합니다. 자세한 내용은 [GitHub Actions에 대한 워크플로 구문](/ko/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)을(를) 참조하세요. ### 예: 경로 포함 하나 이상의 경로가 `paths` 필터의 패턴과 일치하면 워크플로가 실행됩니다. 예를 들어 JavaScript 파일(`.js`)을 푸시할 때마다 다음 워크플로가 실행됩니다. ```yaml on: push: paths: - '**.js' ``` 경로 필터링, [분기 필터링](/ko/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore) 또는 [커밋 메시지](/ko/actions/managing-workflow-runs/skipping-workflow-runs)로 인해 워크플로를 건너뛰는 경우 해당 워크플로와 연결된 검사는 “보류 중” 상태로 유지됩니다. 이러한 검사가 성공해야 하는 끌어오기 요청은 병합에서 차단됩니다. ### 예: 경로 제외 모든 경로 이름이 `paths-ignore`의 패턴과 일치하면 워크플로가 실행되지 않습니다. 경로 이름이 `paths-ignore`의 패턴과 일치하지 않는 경우 일부 경로 이름이 패턴과 일치하더라도 워크플로가 실행됩니다. 다음 경로 필터가 있는 워크플로는 리포지토리의 루트에 있는 `docs` 디렉터리 외부에 하나 이상의 파일이 포함된 `push` 이벤트에서만 실행됩니다. ```yaml on: push: paths-ignore: - 'docs/**' ``` ### 예: 경로 포함 및 제외 `paths` 및 `paths-ignore`를 사용하여 단일 워크플로의 동일한 이벤트를 필터링할 수 없습니다. 단일 이벤트에 대한 경로 패턴을 포함 및 제외하려면 접두어 `!` 문자와 함께 `paths` 필터를 사용하여 제외해야 하는 경로를 나타냅니다. `!` 문자를 사용하여 경로를 정의하는 경우 `!` 문자 없이 하나 이상의 경로도 정의해야 합니다. 경로만 제외하려면 `paths-ignore`를 대신 사용합니다. `paths` 패턴을 정의하는 순서가 중요합니다. * 긍정 일치 후 일치하는 부정 패턴(접두사 `!`)은 경로를 제외합니다. * 부정 일치 후 일치하는 긍정 패턴은 경로를 다시 포함합니다. 이 예제에서는 `sub-project/docs` 디렉터리에 파일이 없는 한 `push` 이벤트가 `sub-project` 디렉터리 또는 해당 하위 디렉터리에 파일을 포함할 때마다 실행됩니다. 예를 들어 `sub-project/index.js` 또는 `sub-project/src/index.js`를 변경한 푸시는 워크플로 실행을 트리거하지만, `sub-project/docs/readme.md`만 변경하는 푸시는 그러지 않습니다. ```yaml on: push: paths: - 'sub-project/**' - '!sub-project/docs/**' ``` ### Git 차이 비교 > \[!NOTE] > 1,000개를 초과하는 커밋을 푸시하거나 GitHub가 시간 제한으로 인해 차이를 생성하지 않는 경우 워크플로가 항상 실행됩니다. 필터는 변경된 파일을 평가하고 `paths-ignore` 또는 `paths` 목록에 따라 이를 실행하여 워크플로 실행 여부를 결정합니다. 변경된 파일이 없으면 워크플로가 실행되지 않습니다. GitHub는 푸시에는 2개의 점 차이를, 끌어오기 요청에는 3개의 점 차이를 사용하여 변경된 파일 목록을 생성합니다. * **끌어오기 요청:** 세 개의 점 차이는 토픽 분기의 최신 버전과 토픽 분기가 기본 분기와 마지막으로 동기화된 커밋을 비교한 것입니다. * **기존 분기로 푸시:** 두 개의 점 차이는 헤드와 기본 SHA를 서로 직접 비교합니다. * **새 분기로 푸시:** 푸시된 가장 깊은 커밋의 상위 부모에 대한 두 개의 점 차이입니다. > \[!NOTE] > 차이는 300개의 파일로 제한됩니다. 필터에서 반환된 처음 300개 파일에서 일치하지 않는 파일이 변경된 경우 워크플로가 실행되지 않습니다. 워크플로가 자동으로 실행되도록 보다 구체적인 필터를 만들어야 할 수 있습니다. 자세한 내용은 [풀 리퀘스트에서 브랜치 비교하기](/ko/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests)을(를) 참조하세요. ## `on.schedule` ``` `on.schedule`을 사용하여 워크플로에 대한 시간 일정을 정의할 수 있습니다. ``` [POSIX cron 구문을](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) 사용하여 특정 시간에 실행되도록 워크플로를 예약합니다. 기본적으로 예약된 워크플로는 UTC로 실행됩니다. 필요에 따라 표준 시간대 인식 일정에 [IANA 표준 시간대 문자열](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) 을 사용하여 표준 시간대를 지정할 수 있습니다. 예약된 워크플로는 기본 분기의 최신 커밋에서 실행됩니다. 예약된 워크플로를 실행할 수 있는 가장 짧은 간격은 5분마다 한 번입니다. > \[!NOTE] > DST(일광 절약 시간제)를 관찰하는 표준 시간대로 설정된 `timezone` 일정의 경우 DST 스프링 포워드 전환 중에 건너뛴 시간에 예약된 워크플로가 다음 유효한 시간으로 진행됩니다. 예를 들어 오전 2시 30분 일정은 오전 3:00까지 진행됩니다. Cron 구문에는 공백으로 구분된 5개의 필드가 있으며 각 필드는 시간 단위를 나타냅니다. ```text ┌───────────── minute (0 - 59) │ ┌───────────── hour (0 - 23) │ │ ┌───────────── day of the month (1 - 31) │ │ │ ┌───────────── month (1 - 12 or JAN-DEC) │ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT) │ │ │ │ │ * * * * * ``` 5개 필드 모두에서 다음과 같은 연산자를 사용할 수 있습니다. | 운영자 | 설명 | 예시 | | --- | ---- | -- | | \* | 모든 값 | | ``` `15 * * * *`의 경우 매일 매시 15분마다 실행됩니다. | ``` \| = | 값 목록 구분 기호 | `2,10 4,5 * * *`의 경우 매일 4번째 및 5번째 시간의 2분과 10분에 실행됩니다. | \| - | 값의 범위 | `30 4-6 * * *`의 경우 4번째, 5번째 및 6번째 시간의 30분에 실행됩니다. | \| / | 단계 값 | 20분부터 59분까지 매 15분마다(`20/15 * * * *`는 20, 35, 그리고 50분에) 실행됩니다. | 이 예제에서는 매주 월요일부터 금요일까지 미국/New\_York 표준 시간대에서 오전 5시 30분에 실행되도록 워크플로를 트리거합니다. ```yaml on: schedule: - cron: '30 5 * * 1-5' timezone: "America/New_York" ``` 단일 워크플로는 여러 `schedule` 이벤트에 의해 트리거될 수 있습니다. `schedule` 컨텍스트를 통해 워크플로를 트리거한 `github.event.schedule` 이벤트에 액세스할 수 있습니다. 이 예제에서는 매주 월\~목요일 5:30(UTC), 화요일과 목요일에는 17:30(UTC)에 실행되도록 워크플로를 트리거하지만 월요일과 수요일에는 `Not on Monday or Wednesday` 단계를 건너뜁니다. ```yaml on: schedule: - cron: '30 5 * * 1,3' - cron: '30 5,17 * * 2,4' jobs: test_schedule: runs-on: ubuntu-latest steps: - name: Not on Monday or Wednesday if: github.event.schedule != '30 5 * * 1,3' run: echo "This step will be skipped on Monday and Wednesday" - name: Every time run: echo "This step will always run" ``` ``` `schedule` 이벤트에 대한 자세한 내용은 [AUTOTITLE](/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule)을(를) 참조하세요. ``` ## `on.workflow_call` ``` `on.workflow_call`을 사용하여 재사용 가능한 워크플로에 대한 입력 및 출력을 정의합니다. 호출된 워크플로에 사용할 수 있는 비밀을 매핑할 수도 있습니다. 재사용 가능한 워크플로에 대한 자세한 내용은 [AUTOTITLE](/actions/using-workflows/reusing-workflows)을(를) 참조하세요. ``` ## `on.workflow_call.inputs` ``` `workflow_call` 키워드를 사용하는 경우 필요에 따라 호출자 워크플로에서 호출된 워크플로로 전달되는 입력을 지정할 수 있습니다. `workflow_call` 키워드 사용에 관한 자세한 내용은 [AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows#workflow-reuse-events)을(를) 참조하세요. ``` 사용할 수 있는 표준 입력 매개 변수 외에도 `on.workflow_call.inputs`에는 `type` 매개 변수가 필요합니다. 자세한 내용은 [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype)을(를) 참조하세요. ``` `default` 매개 변수가 설정되지 않은 경우 입력의 기본값은 부울의 경우 `false`, 숫자의 경우 `0`, 문자열의 경우 `""`입니다. ``` 호출된 워크플로 내에서 `inputs` 컨텍스트를 사용하여 입력을 참조할 수 있습니다. 자세한 내용은 [문맥 참조](/ko/actions/learn-github-actions/contexts#inputs-context)을(를) 참조하세요. 호출자 워크플로가 호출된 워크플로에 지정되지 않은 입력을 전달하면 오류가 발생합니다. ### ``` `on.workflow_call.inputs`의 예 ``` ```yaml on: workflow_call: inputs: username: description: 'A username passed from the caller workflow' default: 'john-doe' required: false type: string jobs: print-username: runs-on: ubuntu-latest steps: - name: Print the input name to STDOUT run: echo The username is ${{ inputs.username }} ``` 자세한 내용은 [워크플로 재사용](/ko/actions/using-workflows/reusing-workflows)을(를) 참조하세요. ## `on.workflow_call.inputs..type` ``` `on.workflow_call` 키워드에 대한 입력이 정의된 경우 필요합니다. 이 매개 변수의 값은 입력의 데이터 형식을 지정하는 문자열입니다. `boolean`, `number` 또는 `string` 중 하나여야 합니다. ``` ## `on.workflow_call.outputs` 호출된 워크플로에 대한 출력의 맵입니다. 호출된 워크플로 출력은 호출자 워크플로의 모든 다운스트림 작업에 사용할 수 있습니다. 각 출력에는 식별자, 선택적 `description,`, `value.`가 있습니다. `value`는 호출된 워크플로 내의 작업에서 출력 값으로 설정해야 합니다. 아래 예제에서는 재사용 가능한 워크플로에 대해 `workflow_output1` 및 `workflow_output2`, 두 개의 출력이 정의됩니다. 해당 출력은 `job_output1` 작업의 `job_output2` 출력과 `my_job`에 매핑됩니다. ### ``` `on.workflow_call.outputs`의 예 ``` ```yaml on: workflow_call: # Map the workflow outputs to job outputs outputs: workflow_output1: description: "The first job output" value: ${{ jobs.my_job.outputs.job_output1 }} workflow_output2: description: "The second job output" value: ${{ jobs.my_job.outputs.job_output2 }} ``` 작업 출력을 참조하는 방법에 대한 자세한 내용은 [`jobs..outputs`](#jobsjob_idoutputs)을(를) 참조하세요. 자세한 내용은 [워크플로 재사용](/ko/actions/using-workflows/reusing-workflows)을(를) 참조하세요. ## `on.workflow_call.secrets` 호출된 워크플로에서 사용할 수 있는 비밀의 맵입니다. 호출된 워크플로 내에서 `secrets` 컨텍스트를 사용하여 비밀을 참조할 수 있습니다. > \[!NOTE] > 중첩된 재사용 가능한 워크플로에 비밀을 전달하는 경우 [`jobs..secrets`](#jobsjob_idsecrets)을(를) 다시 사용하여 비밀을 전달해야 합니다. 자세한 내용은 [워크플로 재사용](/ko/actions/using-workflows/reusing-workflows#passing-secrets-to-nested-workflows)을(를) 참조하세요. 호출자 워크플로가 호출된 워크플로에 지정되지 않은 비밀을 전달하면 오류가 발생합니다. ### ``` `on.workflow_call.secrets`의 예 ``` ```yaml on: workflow_call: secrets: access-token: description: 'A token passed from the caller workflow' required: false jobs: pass-secret-to-action: runs-on: ubuntu-latest steps: # passing the secret to an action - name: Pass the received secret to an action uses: ./.github/actions/my-action with: token: ${{ secrets.access-token }} # passing the secret to a nested reusable workflow pass-secret-to-workflow: uses: ./.github/workflows/my-workflow secrets: token: ${{ secrets.access-token }} ``` ## `on.workflow_call.secrets.` 비밀과 연결할 문자열 식별자입니다. ## `on.workflow_call.secrets..required` 비밀을 제공해야 하는지 여부를 지정하는 부울입니다. ## `on.workflow_run.` `workflow_run` 이벤트를 사용하는 경우 워크플로를 트리거하기 위해 트리거 워크플로를 실행해야 하는 분기를 지정할 수 있습니다. ``` `branches` 및 `branches-ignore` 필터는 `*`, `**`, `+`, `?`, `!` 및 그 외 두 개 이상의 분기 이름에 대한 일치 판정을 위한 문자 등의 문자를 사용하는 GLOB 패턴을 허용합니다. 이름에 해당 문자가 포함되어 있고 리터럴 일치를 원하는 경우 각 특수 문자를 __ 로 `\`해야 합니다. glob 패턴에 대한 자세한 내용은 [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)을(를) 참조하세요. ``` 예를 들어 다음 트리거가 있는 워크플로는 이름이 `Build`로 시작하는 분기에서 `releases/`라는 워크플로가 실행되는 경우에만 실행됩니다. ```yaml on: workflow_run: workflows: ["Build"] types: [requested] branches: - 'releases/**' ``` 다음 트리거가 있는 워크플로는 이름이 `Build`가 아닌 분기에서 `canary`라는 워크플로가 실행되는 경우에만 실행됩니다. ```yaml on: workflow_run: workflows: ["Build"] types: [requested] branches-ignore: - "canary" ``` 워크플로의 동일한 이벤트에 대해 `branches` 필터와 `branches-ignore` 필터 둘 다는 사용할 수 없습니다. 단일 이벤트에 대한 분기 패턴을 포함 및 제외하려면 `branches` 문자와 함께 `!` 필터를 사용하여 제외해야 하는 분기를 나타냅니다. 패턴을 정의하는 순서가 중요합니다. * 긍정 일치 후 일치하는 부정 패턴(접두사 `!`)은 분기를 제외합니다. * 부정 일치 후 일치하는 긍정 패턴은 분기를 다시 포함합니다. 예를 들어 다음 트리거가 있는 워크플로는 이름이 `Build` 또는 `releases/10`인 분기에서 `releases/beta/mona`라는 워크플로가 실행되는 경우에만 실행되며 분기 이름이 `releases/10-alpha`, `releases/beta/3-alpha` 또는 `main`인 경우에는 그러지 않습니다. ```yaml on: workflow_run: workflows: ["Build"] types: [requested] branches: - 'releases/**' - '!releases/**-alpha' ``` ## `on.workflow_dispatch` `workflow_dispatch` 이벤트를 사용할 때 필요에 따라 워크플로에 전달되는 입력을 지정할 수 있습니다. 이 트리거는 워크플로 파일이 기본 브랜치에 있을 때만 이벤트를 수신합니다. ## `on.workflow_dispatch.inputs` 트리거된 워크플로는 `inputs` 컨텍스트에서 입력을 받습니다. 자세한 내용은 [컨텍스트](/ko/actions/learn-github-actions/contexts#inputs-context)를 참조하세요. > \[!NOTE] > > * 워크플로는 `github.event.inputs` 컨텍스트의 입력도 수신합니다. > `inputs` 컨텍스트와 `github.event.inputs` 컨텍스트의 정보는 `inputs` 컨텍스트가 부울 값을 문자열로 변환하는 대신 부울 값으로 유지한다는 점을 제외하고 동일합니다. 이 `choice` 형식은 문자열로 확인되며 단일 선택 가능한 옵션입니다. > * 최상위 속성 `inputs` 의 최대 수는 25 입니다. > * 최대 페이로드 `inputs`는 65,535자입니다. ### ``` `on.workflow_dispatch.inputs`의 예 ``` ```yaml on: workflow_dispatch: inputs: logLevel: description: 'Log level' required: true default: 'warning' type: choice options: - info - warning - debug print_tags: description: 'True to print to STDOUT' required: true type: boolean tags: description: 'Test scenario tags' required: true type: string environment: description: 'Environment to run tests against' type: environment required: true jobs: print-tag: runs-on: ubuntu-latest if: ${{ inputs.print_tags }} steps: - name: Print the input tag to STDOUT run: echo The tags are ${{ inputs.tags }} ``` ## `on.workflow_dispatch.inputs..required` 입력을 제공해야 하는지 여부를 지정하는 부울입니다. ## `on.workflow_dispatch.inputs..type` 이 매개 변수의 값은 입력의 데이터 형식을 지정하는 문자열입니다. `boolean`, `choice`, `number`, `environment` 또는 `string` 중 하나여야 합니다. ## `permissions` `permissions`를 사용하여 `GITHUB_TOKEN`에 부여된 기본 사용 권한을 수정하면 필요에 따라 액세스를 추가하거나 제거하여 필요한 최소 액세스만 허용할 수 있습니다. 자세한 내용은 [워크플로에서 인증에 GITHUB\_TOKEN 사용](/ko/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token)을(를) 참조하세요. ``` `permissions`를 최상위 키로 사용하거나, 워크플로의 모든 작업에 적용하거나, 특정 작업 내에서 적용할 수 있습니다. 특정 작업 내에 `permissions` 키를 추가하면 `GITHUB_TOKEN`을 사용하는 해당 작업 내의 모든 동작 및 실행 명령이 지정한 액세스 권한을 얻게 됩니다. 자세한 내용은 [`jobs..permissions`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions)를 참조하세요. ``` 조직의 소유자는 리포지토리 수준에서 `GITHUB_TOKEN`에 대한 쓰기 액세스를 제한할 수 있습니다. 자세한 정보는 [조직에 대한 GitHub Actions 사용하지 않도록 설정 또는 제한](/ko/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization)." 워크플로가 [`pull_request_target`](/ko/actions/using-workflows/events-that-trigger-workflows#pull_request_target) 이벤트에 의해 트리거되면, `GITHUB_TOKEN`는 퍼블릭 포크에서 트리거되는 경우에도 읽기/쓰기 리포지토리 권한이 부여됩니다. 자세한 내용은 [워크플로를 트리거하는 이벤트](/ko/actions/using-workflows/events-that-trigger-workflows#pull_request_target)을(를) 참조하세요. 아래 표에 표시된 사용 가능한 각 권한에 대해 `read`(해당되는 경우) `write` 또는 `none` 액세스 수준 중 하나를 할당할 수 있습니다. `write`에는 `read`이(가) 포함됩니다. 이러한 권한에 대한 액세스를 지정하면 지정되지 않은 모든 권한은 `none`(으)로 설정됩니다. 사용 가능한 권한과 각 작업에서 수행할 수 있는 작업에 대한 세부 정보: | 사용 권한 | Allows an action using `GITHUB_TOKEN`을(를) 사용하여 작업을 허용합니다. | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `actions` | GitHub Actions로 작업합니다. 예를 들어, `actions: write`에서 워크플로 실행을 취소하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions)을(를) 참조하세요. | | | | | `artifact-metadata` | 아티팩트 메타데이터를 사용합니다. 예를 들어 `artifact-metadata: write` 작업이 빌드 아티팩트를 대신하여 스토리지 레코드를 만들도록 허용합니다. 자세한 내용은 [아티팩트 메타데이터에 대한 REST API 엔드포인트](/ko/rest/orgs/artifact-metadata?apiVersion=2022-11-28)을(를) 참조하세요. | | | | | | | | `attestations` | 아티팩트 증명으로 작업합니다. 예를 들어 `attestations: write`에서 작업이 빌드에 대한 아티팩트 증명을 생성하도록 허용합니다. 자세한 내용은 [아티팩트 증명을 사용하여 빌드의 출처 설정](/ko/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)을(를) 참조하세요. | | | | | `checks` | 검사 실행 및 검사 도구 모음으로 작업합니다. 예를 들어, `checks: write`에서 작업이 검사 실행을 생성하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks)을(를) 참조하세요. | | `contents` | 리포지토리의 콘텐츠로 작업합니다. 예를 들어 `contents: read`에서는 작업이 커밋을 나열하도록 허용하고, `contents: write`에서는 작업이 릴리스를 만들 수 있도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents)을(를) 참조하세요. | | `deployments` | 배포를 통해 작업합니다. 예를 들어, `deployments: write`에서는 작업이 새 배포를 만들도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments)을(를) 참조하세요. | | `discussions` | GitHub Discussion로 작업합니다. 예를 들어 `discussions: write`에서 작업이 토론을 종료하거나 삭제하도록 허용합니다. 자세한 내용은 [토론에 GraphQL API 사용](/ko/graphql/guides/using-the-graphql-api-for-discussions)을(를) 참조하세요. | | | | | `id-token` | OIDC(OpenID Connect) 토큰을 가져옵니다. | ``` `id-token: write`여야 합니다. 자세한 내용은 [AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc)을(를) 참조하세요. | ``` \| | \| `issues` | 문제로 작업합니다. 예를 들어 `issues: write`에서 작업이 문제에 주석을 추가하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues)을(를) 참조하세요. | \| | \| `models` | 를 사용하여 GitHub ModelsAI 유추 응답 생성 예를 들어, `models: read`은 작업이 GitHub Models 유추 API를 사용할 수 있도록 허용합니다. [AI 모델을 사용하여 프로토타이핑](/ko/github-models/prototyping-with-ai-models)을(를) 참조하세요. | \| | \| `packages` | GitHub 패키지로 작업합니다. 예를 들어, `packages: write`에서 작업이 GitHub 패키지에 패키지를 업로드하고 게시하도록 허용합니다. 자세한 내용은 [GitHub 패키지에 대한 사용 권한 정보](/ko/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries)을(를) 참조하세요. | \| `pages` | GitHub Pages로 작업합니다. 예를 들어 `pages: write`에서 작업이 GitHub Pages 빌드를 요청하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages)을(를) 참조하세요. | \| `pull-requests` | 끌어오기 요청으로 작업합니다. 예를 들어 `pull-requests: write`에서 작업이 끌어오기 요청에 레이블을 추가하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests)을(를) 참조하세요. | \| | \| `security-events` | GitHub 코드 검사 경고로 작업합니다. 예를 들어 `security-events: read`에서 작업이 리포지토리에 대해 코드 검사 경고를 나열하도록 허용하고, `security-events: write`에서는 작업이 코드 검사 경고의 상태를 업데이트하도록 허용합니다. 자세한 내용은 ["코드 검색 경고"에 대한 리포지토리 권한을 참조하세요](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts).

Dependabot 경고의 경우 사용 권한을 사용합니다 `vulnerability-alerts` . 비밀 검색 경고는 이 권한으로 읽을 수 없으며 GitHub 앱 또는 personal access token이 필요합니다. 자세한 내용은 "GitHub 앱 [에 필요한 권한"의 "비밀 검사 경고"에 대한 리포지토리](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) 권한을 참조하세요. | \| `statuses` | 커밋 상태로 작업합니다. 예를 들어 `statuses:read`에서 작업이 지정된 참조에 대한 커밋 상태 나열하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses)을(를) 참조하세요. | \| | \| `vulnerability-alerts` | Dependabot 경고를 읽습니다. 예를 들어 `vulnerability-alerts: read` 작업이 리포지토리에 대한 Dependabot 경고를 나열하도록 허용합니다. 오직 `read`과 `none`만 지원되며, `write`은 유효하지 않습니다. `write-all` 또는 `read-all`이 사용될 때, `vulnerability-alerts`가 자동으로 `read`로 포함됩니다. 자세한 내용은 ["Dependabot 경고"에 대한 리포지토리 권한을 참조하세요](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts). | \| | ### ``` `GITHUB_TOKEN` 범위에 대한 액세스 정의 ``` `GITHUB_TOKEN` 키 내에서 사용 가능한 권한의 값으로 `read`, `write`, `none`을 지정하여 `permissions`이 허용할 액세스를 정의할 수 있습니다. ```yaml permissions: actions: read|write|none artifact-metadata: read|write|none attestations: read|write|none checks: read|write|none contents: read|write|none deployments: read|write|none id-token: write|none issues: read|write|none models: read|none discussions: read|write|none packages: read|write|none pages: read|write|none pull-requests: read|write|none security-events: read|write|none statuses: read|write|none vulnerability-alerts: read|none ``` 이러한 권한에 대한 액세스를 지정하면 지정되지 않은 모든 권한은 `none`으로 설정됩니다. 다음 구문을 사용하여 사용 가능한 모든 권한에 대한 `read-all` 또는 `write-all` 액세스 중 하나를 정의할 수 있습니다. ```yaml permissions: read-all ``` ```yaml permissions: write-all ``` 다음 구문을 사용하여 사용 가능한 모든 권한에 대한 사용 권한을 사용하지 않도록 설정할 수 있습니다. ```yaml permissions: {} ``` #### 포크된 리포지토리의 권한 변경 또한 `permissions` 키를 사용하여 포크된 리포지토리에 대한 읽기 권한을 추가 및 제거할 수 있지만 일반적으로 쓰기 액세스 권한은 부여할 수 없습니다. 이 동작의 예외는 관리 사용자가 GitHub Actions 설정의 **끌어오기 요청에서 워크플로에 쓰기 토큰 보내기** 옵션을 선택한 경우입니다. 자세한 내용은 [리포지토리에 대한 GitHub Actions 설정 관리](/ko/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks)을(를) 참조하세요. ## 워크플로 작업에 대한 사용 권한을 계산하는 방법 ``` `GITHUB_TOKEN`에 대한 권한은 처음에 엔터프라이즈, 조직 또는 리포지토리의 기본 설정으로 설정됩니다. 기본값이 이러한 수준에서 제한된 권한으로 설정된 경우 관련 리포지토리에 적용됩니다. 예를 들어 조직 수준에서 제한된 기본값을 선택하는 경우 해당 조직의 모든 리포지토리는 제한된 권한을 기본값으로 사용합니다. 그런 다음 워크플로 파일 내의 구성에 따라 먼저 워크플로 수준에서 그리고 작업 수준에서 차례로 권한을 조정합니다. 마지막으로 포크된 리포지토리가 아닌 `pull_request_target` 끌어오기 요청 이벤트에 의해 워크플로가 트리거되고 **끌어오기 요청 설정에서 워크플로에 쓰기 토큰 보내기** 가 선택되지 않은 경우 읽기 전용으로 쓰기 권한을 변경하도록 권한이 조정됩니다. ``` ### 워크플로의 모든 작업에 대한 `GITHUB_TOKEN` 권한 설정 워크플로의 최상위 수준에서 `permissions`을(를) 지정하여 워크플로의 모든 작업에 설정이 적용되도록 할 수 있습니다. #### 예시: 전체 워크플로에 `GITHUB_TOKEN` 권한 설정 이 예제에서는 워크플로의 모든 작업에 적용되는 `GITHUB_TOKEN`에 대해 설정되는 사용 권한을 보여 줍니다. 모든 권한에는 읽기 액세스 권한이 부여됩니다. ```yaml name: "My workflow" on: [ push ] permissions: read-all jobs: ... ``` ### 포크된 리포지토리에 `permissions` 키 사용 또한 `permissions` 키를 사용하여 분기된 리포지토리에 대한 `read` 권한을 추가 및 제거할 수 있지만 일반적으로 `write` 액세스 권한은 부여할 수 없습니다. 이 동작에 대한 예외는 관리자가 설정의 **끌어오기 요청 옵션에서 워크플로에 쓰기 토큰 보내기** 옵션을 GitHub Actions 선택한 경우입니다. 자세한 내용은 [리포지토리에 대한 GitHub Actions 설정 관리](/ko/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks)을(를) 참조하세요. ### 트리거된 워크플로 실행에 대한 Dependabot의 권한 Dependabot 끌어오기 요청에 의해 트리거되는 워크플로 실행은 포크된 리포지토리에서 온 것처럼 실행되므로 읽기 전용 `GITHUB_TOKEN`을 사용합니다. 이러한 워크플로 실행은 비밀에 액세스할 수 없습니다. 워크플로의 안전한 유지를 위한 전략의 자세한 내용은 [안전 사용 참조](/ko/actions/security-guides/security-hardening-for-github-actions)을(를) 참조하세요. ## `env` 워크플로의 모든 작업 단계에서 사용할 수 있는 `map` 변수. 단일 작업의 단계 또는 단일 단계에만 사용할 수 있는 변수를 설정할 수도 있습니다. 자세한 내용은 [`jobs..env`](#jobsjob_idenv) 및 [`jobs..steps[*].env`](#jobsjob_idstepsenv)을(를) 참조하세요. ``` `env` 맵의 변수는 맵의 다른 변수를 기준으로 정의할 수 없습니다. ``` 둘 이상의 변수가 동일한 이름으로 정의되면 GitHub는 가장 구체적인 환경 변수를 사용합니다. 예를 들어 단계에 정의된 환경 변수는 단계가 실행되는 동안 동일한 이름의 작업 및 워크플로 환경 변수를 재정의합니다. 작업에 정의된 환경 변수는 작업이 실행되는 동안 동일한 이름의 워크플로 변수를 재정의합니다. ### ``` `env`의 예 ``` ```yaml env: SERVER: production ``` ## `defaults` `defaults`를 사용하여 워크플로의 모든 작업에 적용할 기본 설정의 `map`을 만듭니다. 작업에만 사용할 수 있는 기본 설정을 지정할 수도 있습니다. 자세한 내용은 [`jobs..defaults`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaults)를 참조하세요. 둘 이상의 기본 설정이 동일한 이름으로 정의되면 GitHub는 가장 구체적인 기본 설정을 사용합니다. 예를 들어 작업에 정의된 기본 설정은 워크플로에 정의된 이름과 동일한 기본 설정을 재정의합니다. ## `defaults.run` `defaults.run`을 사용하여 워크플로의 모든 [`run`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) 단계에 기본 `shell` 및 `working-directory` 옵션을 제공할 수 있습니다. 작업에만 사용할 수 있는 `run`에 대한 기본 설정을 지정할 수도 있습니다. 자세한 내용은 [`jobs..defaults.run`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun)를 참조하세요. 이 키워드에는 컨텍스트 또는 식을 사용할 수 없습니다. 둘 이상의 기본 설정이 동일한 이름으로 정의되면 GitHub는 가장 구체적인 기본 설정을 사용합니다. 예를 들어 작업에 정의된 기본 설정은 워크플로에 정의된 이름과 동일한 기본 설정을 재정의합니다. ### 예: 기본 셸 및 작업 디렉터리 설정 ```yaml defaults: run: shell: bash working-directory: ./scripts ``` ## `defaults.run.shell` `shell`을(를) 사용하여 단계의 `shell`을(를) 정의합니다. 키워드는 여러 컨텍스트를 참조할 수 있습니다. 자세한 내용은 [컨텍스트](/ko/actions/learn-github-actions/contexts#context-availability)를 참조하세요. | 지원되는 플랫폼 | `shell` 매개 변수 | 설명 | 내부적으로 명령 실행 | | ------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | Linux / macOS | unspecified | 비 Windows 플랫폼의 기본 셸입니다. `bash`가 명시적으로 지정된 경우와는 다른 명령을 실행한다는 점에 유의하세요. `bash`를 경로에서 찾을 수 없는 경우, `sh`로 처리됩니다. | `bash -e {0}` | | 모두 | `bash` | `sh`로의 대체가 있는 비 Windows 플랫폼의 기본 셸입니다. Windows에서 bash 셸을 지정할 때 Windows용 Git에 포함된 bash 셸이 사용됩니다. | `bash --noprofile --norc -eo pipefail {0}` | | 모두 | `pwsh` | PowerShell Core입니다. GitHub가 스크립트 이름에 `.ps1` 확장을 추가합니다. | `pwsh -command ". '{0}'"` | | 모두 | `python` | Python 명령을 실행합니다. | `python {0}` | | Linux / macOS | `sh` | 셸이 제공되지 않고 경로에 `bash`가 없는 경우 비 Windows 플랫폼에 대한 대체 동작입니다. | `sh -e {0}` | | Windows | `cmd` | GitHub는 스크립트 이름에 `.cmd` 확장을 추가하고 `{0}`로 대체합니다. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. | | Windows | `pwsh` | Windows에서 사용되는 기본 셸입니다. PowerShell Core입니다. GitHub가 스크립트 이름에 `.ps1` 확장을 추가합니다. 자체 호스팅 Windows 실행기에 \_PowerShell Core\_가 설치되어 있지 않으면 \_PowerShell Desktop\_이 대신 사용됩니다. | `pwsh -command ". '{0}'"`. | | Windows | `powershell` | PowerShell 데스크톱입니다. GitHub가 스크립트 이름에 `.ps1` 확장을 추가합니다. | `powershell -command ". '{0}'"`. | 둘 이상의 기본 설정이 동일한 이름으로 정의되면 GitHub는 가장 구체적인 기본 설정을 사용합니다. 예를 들어 작업에 정의된 기본 설정은 워크플로에 정의된 이름과 동일한 기본 설정을 재정의합니다. ## `defaults.run.working-directory` `working-directory`을(를) 사용하여 단계의 `shell`에 대한 작업 디렉터리를 정의합니다. 키워드는 여러 컨텍스트를 참조할 수 있습니다. 자세한 내용은 [컨텍스트](/ko/actions/learn-github-actions/contexts#context-availability)를 참조하세요. > \[!TIP] > 셸을 실행하기 전에 할당한 `working-directory`가 실행기에 존재하는지 확인합니다. > 둘 이상의 기본 설정이 동일한 이름으로 정의되면 GitHub는 가장 구체적인 기본 설정을 사용합니다. 예를 들어 작업에 정의된 기본 설정은 워크플로에 정의된 이름과 동일한 기본 설정을 재정의합니다. ## `concurrency` `concurrency`를 사용하여 동일한 동시성 그룹을 사용하는 작업 또는 워크플로가 한 번에 하나만 실행되도록 합니다. 동시성 그룹은 모든 문자열 또는 식일 수 있습니다. 식은 [`github`](/ko/actions/learn-github-actions/contexts#github-context), [`inputs`](/ko/actions/learn-github-actions/contexts#inputs-context), [`vars`](/ko/actions/learn-github-actions/contexts#vars-context)컨텍스트만 사용할 수 있습니다. 식에 대한 자세한 내용은 [워크플로 및 작업에서 식 평가](/ko/actions/learn-github-actions/expressions)을(를) 참조하세요. 작업 수준에서 `concurrency`를 지정할 수도 있습니다. 자세한 내용은 [`jobs..concurrency`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency)를 참조하세요. 다시 말해 동시성 그룹 하나에는 한 번에 실행 중인 작업 최대 한 개, 보류 중인 작업 최대 한 개만 있을 수 있습니다. 동시 작업 또는 워크플로가 큐에 대기 중인 경우 리포지토리의 동일한 동시성 그룹을 사용하는 다른 작업 또는 워크플로가 진행 중이면 대기 중인 작업 또는 워크플로는 `pending` 상태가 됩니다. 동일한 동시성 그룹에 있는 모든 기존 `pending` 작업 또는 워크플로가 있는 경우 취소되고 대기 중인 새 작업 또는 워크플로가 대신 수행됩니다. 동일한 동시성 그룹에서 현재 실행 중인 작업 또는 워크플로도 취소하려면 `cancel-in-progress: true`를 지정합니다. 동일한 동시성 그룹에서 현재 실행 중인 작업이나 워크플로를 조건부 취소하려면, 허용된 모든 식 컨텍스트에서 `cancel-in-progress`을(를) 식으로 지정하면 됩니다. > \[!NOTE] > > * 동시성 그룹 이름은 대/소문자를 구분하지 않습니다. 예를 들어 `prod` 및 `Prod`는 동일한 동시성 그룹으로 처리됩니다. > * 동시성 그룹을 사용하는 작업 또는 워크플로 실행에 대해서는 순서가 보장되지 않습니다. 동일한 동시성 그룹에서 작업 또는 워크플로 실행은 임의의 순서로 처리됩니다. ### 예: 동시성 및 기본 동작 사용 GitHub Actions의 기본 동작은 여러 작업 또는 워크플로 실행이 동시에 실행되도록 하는 것입니다. `concurrency` 키워드를 사용하면 워크플로 실행의 동시성을 제어할 수 있습니다. 예를 들어 트리거 조건이 정의된 직후에 `concurrency` 키워드를 사용하면 특정 분기에 대한 전체 워크플로 실행의 동시성을 제한할 수 있습니다. ```yaml on: push: branches: - main concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` 작업 수준에서 `concurrency` 키워드를 사용하여 워크플로 내에서 작업의 동시성을 제한할 수도 있습니다. ```yaml on: push: branches: - main jobs: job-1: runs-on: ubuntu-latest concurrency: group: example-group cancel-in-progress: true ``` ### 예: 동시성 그룹 동시성 그룹은 워크플로 실행 또는 동일한 동시성 키를 공유하는 작업의 실행을 관리하고 제한하는 방법을 제시합니다. 이 `concurrency` 키는 워크플로 또는 작업을 함께 동시성 그룹으로 그룹화하는 데 사용됩니다. `concurrency` 키를 정의할 때 GitHub Actions은(는) 지정된 시간에 해당 키를 가진 하나의 워크플로 또는 작업만 실행되도록 합니다. 새 워크플로가 실행되거나 작업이 동일한 `concurrency` 키로 시작하는 경우 GitHub Actions은(는) 해당 키로 이미 실행 중인 워크플로 또는 작업을 취소합니다. `concurrency` 키는 하드 코딩된 문자열이거나 컨텍스트 변수를 포함하는 동적 식일 수 있습니다. 워크플로 또는 작업이 동시성 그룹의 일부가 되도록 워크플로에서 동시성 조건을 정의할 수 있습니다. 즉, 워크플로 실행 또는 작업이 시작되면 GitHub는 동일한 동시성 그룹에서 이미 진행 중인 워크플로 실행 또는 작업을 취소합니다. 이는 충돌을 일으키거나 필요한 것보다 더 많은 리소스를 사용할 수 있는 작업을 방지하기 위해 스테이징 환경에 배포하는 데 사용되는 것과 같은 특정 워크플로 또는 작업 집합에 대한 병렬 실행을 방지하려는 시나리오에서 유용합니다. 이 예제에서 `job-1`은 이름이 `staging_environment`인 동시성 그룹의 일부입니다. 즉, 새로 실행된 `job-1`이 트리거되면 `staging_environment` 동시성 그룹에서 이미 진행 중인 동일한 작업의 실행이 취소됩니다. ```yaml jobs: job-1: runs-on: ubuntu-latest concurrency: group: staging_environment cancel-in-progress: true ``` 또는 워크플로에서 동적 식(예: `concurrency: ci-${{ github.ref }}`)을 사용하면 워크플로 또는 작업이 워크플로를 트리거한 분기 또는 태그의 참조 앞에 이름이 `ci-`인 동시성 그룹의 일부가 됩니다. 이 예제에서는 이전 실행이 진행 중인 동안 새 커밋이 기본 분기에 푸시되면 이전 실행이 취소되고 새 커밋이 시작됩니다. ```yaml on: push: branches: - main concurrency: group: ci-${{ github.ref }} cancel-in-progress: true ``` ### 예: 동시성을 사용하여 진행 중인 작업 또는 실행 취소 동시성을 사용하여 GitHub Actions에서 진행 중인 작업 또는 실행을 취소하려면 `true`로 설정된 `cancel-in-progress` 옵션을 통해 `concurrency` 키를 사용할 수 있습니다. ```yaml concurrency: group: ${{ github.ref }} cancel-in-progress: true ``` 이 예제에서는 특정 동시성 그룹을 정의하지 않고 GitHub Actions은(는) 진행 중인 *모든* 작업 또는 워크플로 실행을 취소합니다. ### 예: 대체 값 사용 특정 이벤트에 대해서만 정의되는 속성으로 그룹 이름을 빌드하는 경우 대체 값을 사용할 수 있습니다. 예를 들어 `github.head_ref`는 `pull_request` 이벤트에서만 정의됩니다. 워크플로가 `pull_request` 이벤트 외에 다른 이벤트에도 응답하는 경우 구문 오류를 방지하기 위해 대체를 제공해야 합니다. 다음 동시성 그룹은 `pull_request` 이벤트에서만 진행 중인 작업 또는 실행을 취소합니다. `github.head_ref`가 정의되지 않은 경우 동시성 그룹은 실행에 고유하고 정의된 실행 ID로 대체됩니다. ```yaml concurrency: group: ${{ github.head_ref || github.run_id }} cancel-in-progress: true ``` ### 예: 현재 워크플로에 대해서만 진행 중인 작업 또는 실행 취소 동일한 리포지토리에 여러 워크플로가 있는 경우 다른 워크플로에서 진행 중인 작업 또는 실행이 취소되지 않도록 워크플로 전체에서 동시성 그룹 이름이 고유해야 합니다. 그렇지 않으면 워크플로에 관계없이 이전에 진행 중이거나 보류 중인 작업이 취소됩니다. 동일한 워크플로의 진행 중인 실행만 취소하기 위해 `github.workflow` 속성을 사용하여 동시성 그룹을 빌드할 수 있습니다. ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` ### 예: 특정 분기에서 진행 중인 작업만 취소 특정 분기에서 진행 중인 작업만 취소하고 나머지는 취소하지 않고자 하는 경우, `cancel-in-progress`을(를) 포함한 조건식을 사용하면 됩니다. 예를 들어 개발 분기에서만 진행 중인 작업을 취소하고 릴리스 분기에서는 취소하지 않으려면 이렇게 하면 됩니다. 릴리스 분기에서 실행 중이 아닌 경우 같은 워크플로의 진행 중인 실행만 취소하려면, 다음과 비슷한 식에 대하여 `cancel-in-progress`을(를) 설정하면 됩니다. ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: ${{ !contains(github.ref, 'release/')}} ``` 이 예시에서는 `release/1.2.3` 분기에 대한 여러 푸시를 실행해도 진행 중인 실행을 취소하지 않습니다. `main`과(와) 같은 다른 분기로 푸시하면 진행 중인 실행이 취소됩니다. ## `jobs` 워크플로 실행은 기본적으로 병렬로 실행되는 하나 이상의 `jobs`로 구성됩니다. 작업을 순차적으로 실행하려면 `jobs..needs` 키워드를 사용하여 다른 작업에 대한 종속성을 정의할 수 있습니다. 각 작업은 `runs-on`으로 지정된 실행기 환경에서 실행됩니다. 워크플로 사용량 한도 내에 있는 한 개수에 제한 없이 작업을 실행할 수 있습니다. 자세한 내용은GitHub에서 호스트되는 실행기 사용량 한도의 경우 [청구 및 사용량](/ko/actions/learn-github-actions/usage-limits-billing-and-administration), 자체 호스팅되는 실행기 사용량 한도의 경우 [작업 제한](/ko/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners)을(를) 각각 참조하세요. 워크플로 실행에서 실행 중인 작업의 고유 식별자를 찾아야 하는 경우 GitHub API를 사용할 수 있습니다. 자세한 내용은 [GitHub Actions의 REST API 엔드포인트](/ko/rest/actions#workflow-jobs)을(를) 참조하세요. ## `jobs.` `jobs.`를 사용하여 작업에 고유 식별자를 지정합니다. `job_id` 키는 문자열이고 해당 값은 작업 구성 데이터 맵입니다. ``를 `jobs` 개체에 고유한 문자열로 바꿔야 합니다. ``는 문자 또는 `_`로 시작해야 하며 영숫자, `-` 또는 `_`만 포함해야 합니다. ### 예: 작업 만들기 이 예제에서는 두 개의 작업이 생성되었으며 해당 `job_id` 값은 `my_first_job`과 `my_second_job`입니다. ```yaml jobs: my_first_job: name: My first job my_second_job: name: My second job ``` ## `jobs..name` `jobs..name`을 사용하여 GitHub UI에 표시되는 작업 이름을 설정합니다. ## `jobs..permissions` 특정 작업의 경우 `jobs..permissions`를 사용하여 `GITHUB_TOKEN`에 부여된 기본 사용 권한을 수정하면 필요에 따라 액세스를 추가하거나 제거하여 필요한 최소 액세스만 허용할 수 있습니다. 자세한 내용은 [워크플로에서 인증에 GITHUB\_TOKEN 사용](/ko/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token)을(를) 참조하세요. 작업 정의 내에서 사용 권한을 지정하여 필요한 경우 각 작업의 `GITHUB_TOKEN`에 대해 다른 사용 권한 집합을 구성할 수 있습니다. 또는 워크플로의 모든 작업에 대한 사용 권한을 지정할 수 있습니다. 워크플로 수준에서 사용 권한을 정의하는 방법에 대한 자세한 내용은 [`permissions`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#permissions)를 참조하세요. 아래 표에 표시된 사용 가능한 각 권한에 대해 `read`(해당되는 경우) `write` 또는 `none` 액세스 수준 중 하나를 할당할 수 있습니다. `write`에는 `read`이(가) 포함됩니다. 이러한 권한에 대한 액세스를 지정하면 지정되지 않은 모든 권한은 `none`(으)로 설정됩니다. 사용 가능한 권한과 각 작업에서 수행할 수 있는 작업에 대한 세부 정보: | 사용 권한 | Allows an action using `GITHUB_TOKEN`을(를) 사용하여 작업을 허용합니다. | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `actions` | GitHub Actions로 작업합니다. 예를 들어, `actions: write`에서 워크플로 실행을 취소하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions)을(를) 참조하세요. | | | | | `artifact-metadata` | 아티팩트 메타데이터를 사용합니다. 예를 들어 `artifact-metadata: write` 작업이 빌드 아티팩트를 대신하여 스토리지 레코드를 만들도록 허용합니다. 자세한 내용은 [아티팩트 메타데이터에 대한 REST API 엔드포인트](/ko/rest/orgs/artifact-metadata?apiVersion=2022-11-28)을(를) 참조하세요. | | | | | | | | `attestations` | 아티팩트 증명으로 작업합니다. 예를 들어 `attestations: write`에서 작업이 빌드에 대한 아티팩트 증명을 생성하도록 허용합니다. 자세한 내용은 [아티팩트 증명을 사용하여 빌드의 출처 설정](/ko/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)을(를) 참조하세요. | | | | | `checks` | 검사 실행 및 검사 도구 모음으로 작업합니다. 예를 들어, `checks: write`에서 작업이 검사 실행을 생성하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks)을(를) 참조하세요. | | `contents` | 리포지토리의 콘텐츠로 작업합니다. 예를 들어 `contents: read`에서는 작업이 커밋을 나열하도록 허용하고, `contents: write`에서는 작업이 릴리스를 만들 수 있도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents)을(를) 참조하세요. | | `deployments` | 배포를 통해 작업합니다. 예를 들어, `deployments: write`에서는 작업이 새 배포를 만들도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments)을(를) 참조하세요. | | `discussions` | GitHub Discussion로 작업합니다. 예를 들어 `discussions: write`에서 작업이 토론을 종료하거나 삭제하도록 허용합니다. 자세한 내용은 [토론에 GraphQL API 사용](/ko/graphql/guides/using-the-graphql-api-for-discussions)을(를) 참조하세요. | | | | | `id-token` | OIDC(OpenID Connect) 토큰을 가져옵니다. | ``` `id-token: write`여야 합니다. 자세한 내용은 [AUTOTITLE](/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc)을(를) 참조하세요. | ``` \| | \| `issues` | 문제로 작업합니다. 예를 들어 `issues: write`에서 작업이 문제에 주석을 추가하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues)을(를) 참조하세요. | \| | \| `models` | 를 사용하여 GitHub ModelsAI 유추 응답 생성 예를 들어, `models: read`은 작업이 GitHub Models 유추 API를 사용할 수 있도록 허용합니다. [AI 모델을 사용하여 프로토타이핑](/ko/github-models/prototyping-with-ai-models)을(를) 참조하세요. | \| | \| `packages` | GitHub 패키지로 작업합니다. 예를 들어, `packages: write`에서 작업이 GitHub 패키지에 패키지를 업로드하고 게시하도록 허용합니다. 자세한 내용은 [GitHub 패키지에 대한 사용 권한 정보](/ko/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries)을(를) 참조하세요. | \| `pages` | GitHub Pages로 작업합니다. 예를 들어 `pages: write`에서 작업이 GitHub Pages 빌드를 요청하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages)을(를) 참조하세요. | \| `pull-requests` | 끌어오기 요청으로 작업합니다. 예를 들어 `pull-requests: write`에서 작업이 끌어오기 요청에 레이블을 추가하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests)을(를) 참조하세요. | \| | \| `security-events` | GitHub 코드 검사 경고로 작업합니다. 예를 들어 `security-events: read`에서 작업이 리포지토리에 대해 코드 검사 경고를 나열하도록 허용하고, `security-events: write`에서는 작업이 코드 검사 경고의 상태를 업데이트하도록 허용합니다. 자세한 내용은 ["코드 검색 경고"에 대한 리포지토리 권한을 참조하세요](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts).

Dependabot 경고의 경우 사용 권한을 사용합니다 `vulnerability-alerts` . 비밀 검색 경고는 이 권한으로 읽을 수 없으며 GitHub 앱 또는 personal access token이 필요합니다. 자세한 내용은 "GitHub 앱 [에 필요한 권한"의 "비밀 검사 경고"에 대한 리포지토리](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) 권한을 참조하세요. | \| `statuses` | 커밋 상태로 작업합니다. 예를 들어 `statuses:read`에서 작업이 지정된 참조에 대한 커밋 상태 나열하도록 허용합니다. 자세한 내용은 [GitHub 앱에 필요한 권한](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses)을(를) 참조하세요. | \| | \| `vulnerability-alerts` | Dependabot 경고를 읽습니다. 예를 들어 `vulnerability-alerts: read` 작업이 리포지토리에 대한 Dependabot 경고를 나열하도록 허용합니다. 오직 `read`과 `none`만 지원되며, `write`은 유효하지 않습니다. `write-all` 또는 `read-all`이 사용될 때, `vulnerability-alerts`가 자동으로 `read`로 포함됩니다. 자세한 내용은 ["Dependabot 경고"에 대한 리포지토리 권한을 참조하세요](/ko/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts). | \| | ### ``` `GITHUB_TOKEN` 범위에 대한 액세스 정의 ``` `GITHUB_TOKEN` 키 내에서 사용 가능한 권한의 값으로 `read`, `write`, `none`을 지정하여 `permissions`이 허용할 액세스를 정의할 수 있습니다. ```yaml permissions: actions: read|write|none artifact-metadata: read|write|none attestations: read|write|none checks: read|write|none contents: read|write|none deployments: read|write|none id-token: write|none issues: read|write|none models: read|none discussions: read|write|none packages: read|write|none pages: read|write|none pull-requests: read|write|none security-events: read|write|none statuses: read|write|none vulnerability-alerts: read|none ``` 이러한 권한에 대한 액세스를 지정하면 지정되지 않은 모든 권한은 `none`으로 설정됩니다. 다음 구문을 사용하여 사용 가능한 모든 권한에 대한 `read-all` 또는 `write-all` 액세스 중 하나를 정의할 수 있습니다. ```yaml permissions: read-all ``` ```yaml permissions: write-all ``` 다음 구문을 사용하여 사용 가능한 모든 권한에 대한 사용 권한을 사용하지 않도록 설정할 수 있습니다. ```yaml permissions: {} ``` #### 포크된 리포지토리의 권한 변경 또한 `permissions` 키를 사용하여 포크된 리포지토리에 대한 읽기 권한을 추가 및 제거할 수 있지만 일반적으로 쓰기 액세스 권한은 부여할 수 없습니다. 이 동작의 예외는 관리 사용자가 GitHub Actions 설정의 **끌어오기 요청에서 워크플로에 쓰기 토큰 보내기** 옵션을 선택한 경우입니다. 자세한 내용은 [리포지토리에 대한 GitHub Actions 설정 관리](/ko/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks)을(를) 참조하세요. #### 예: 워크플로에서 한 작업에 대한 `GITHUB_TOKEN` 권한 설정 이 예제에서는 이름이 `stale`로 지정된 작업에만 적용되는 `GITHUB_TOKEN`에 대해 설명되는 사용 권한을 보여 줍니다. `issues` 및 `pull-requests` 권한에 대한 쓰기 권한이 부여됩니다. 다른 모든 권한은 액세스할 수 없습니다. ```yaml jobs: stale: runs-on: ubuntu-latest permissions: issues: write pull-requests: write steps: - uses: actions/stale@v10 ``` ## `jobs..needs` 이 작업이 실행되기 전에 완료해야 하는 작업을 식별하는 데 `jobs..needs`를 사용합니다. 문자열 또는 문자열 배열일 수 있습니다. 작업을 실패하거나 건너뛰게 되면 작업이 계속되도록 하는 조건식을 사용하지 않는 한 작업이 필요한 모든 작업을 건너뜁니다. 실행에 서로 필요한 일련의 작업이 포함된 경우 오류 또는 건너뛴 지점부터 종속성 체인의 모든 작업에 오류 및 건너뛰기가 적용됩니다. 종속된 작업이 성공하지 못한 경우에도 작업을 실행하려면 `jobs..if`에 `always()` 조건식을 사용합니다. ### 예: 성공적인 종속 작업 요구 ```yaml jobs: job1: job2: needs: job1 job3: needs: [job1, job2] ``` 이 예제에서 `job1`은 `job2`가 시작되기 전에 성공적으로 완료해야 하며 `job3`은 `job1` 및 `job2` 모두 완료되기를 기다립니다. 이 예제의 작업은 순차적으로 실행됩니다. 1. `job1` 2. `job2` 3. `job3` ### 예: 성공적인 종속 작업이 필요하지 않음 ```yaml jobs: job1: job2: needs: job1 job3: if: ${{ always() }} needs: [job1, job2] ``` 이 예제에서 `job3`은 `always()` 조건식을 사용하여 성공 여부에 관계없이 `job1` 및 `job2`가 완료된 후에 항상 실행되도록 합니다. 자세한 내용은 [워크플로 및 작업에서 식 평가](/ko/actions/learn-github-actions/expressions#status-check-functions)을(를) 참조하세요. ## `jobs..if` `jobs..if` 조건부를 사용하여 조건이 충족되지 않는 한, 작업이 실행되지 않도록 할 수 있습니다. 지원되는 컨텍스트 및 식을 사용하여 조건을 만들 수 있습니다. 이 키에서 지원되는 컨텍스트에 대한 자세한 내용은 [문맥 참조](/ko/actions/learn-github-actions/contexts#context-availability)을(를) 참조하세요. > \[!NOTE] > [`jobs..strategy.matrix`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix)이 적용되기 전 `jobs..if` 상태로 평가합니다. `if` 조건에서 식을 사용하는 경우, 선택에 따라 식 구문(`${{ }}`)을 생략해도 됩니다. GitHub Actions에서 자동으로 `if` 조건을 식으로 평가하기 때문입니다. 그러나, 이 예외는 어디에나 적용되지는 않습니다. `${{ }}` 식 구문을 사용하거나 `!`이 YAML 형식으로 예약된 표기법이므로 `!` 식이 시작될 때 항상 `''`, `""`, `()` 이스케이프를 사용해야 합니다. 예시: ```yaml if: ${{ ! startsWith(github.ref, 'refs/tags/') }} ``` 자세한 내용은 [워크플로 및 작업에서 식 평가](/ko/actions/learn-github-actions/expressions)을(를) 참조하세요. ### 예: 특정 리포지토리에 대해서만 작업 실행 이 예제에서는 `if`를 사용하여 `production-deploy` 작업을 실행할 수 있는 시기를 제어합니다. 리포지토리 이름이 `octo-repo-prod`이고 `octo-org` 조직 내에 있는 경우에만 작업이 실행됩니다. 그렇지 않으면 작업이 ‘건너뛴 것’으로 표시됩니다.\_\_ ```yaml copy name: example-workflow on: [push] jobs: production-deploy: if: github.repository == 'octo-org/octo-repo-prod' runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v4 with: node-version: '14' - run: npm install -g bats ``` ## `jobs..runs-on` `jobs..runs-on`을 사용하여 작업을 실행할 머신 형식을 정의합니다. * 대상 컴퓨터는 [GitHub호스티드 실행기](#choosing-github-hosted-runners), [더 큰 실행기](#choosing-runners-in-a-group) 또는 [자체 호스팅 실행기](#choosing-self-hosted-runners)일 수 있습니다. - 할당된 레이블 또는 그룹 멤버 자격 또는 이러한 조합에 따라 러너를 대상으로 지정할 수 있습니다. - `runs-on`을(를) 다음으로 제공할 수 있습니다. * 단일 문자열 * 문자열을 포함하는 단일 변수 * 문자열 배열 하나, 문자열이 포함된 변수 또는 둘 다의 조합 * `group` 또는 `labels` 키를 사용하는 `key: value`쌍 - 문자열 또는 변수 배열을 지정하면 워크플로가 지정된 모든 `runs-on` 값과 일치하는 실행기에서 실행됩니다. 예를 들어 여기서 작업은 `linux`, `x64`, `gpu` 레이블이 있는 자체 호스팅 실행기에서만 실행되며 다음을 수행합니다. ```yaml runs-on: [self-hosted, linux, x64, gpu] ``` 자세한 내용은 [자체 호스트 실행기 선택](#choosing-self-hosted-runners)을 참조하세요. - 배열 안에서 문자열과 변수를 혼합할 수 있습니다. 예시: ```yaml on: workflow_dispatch: inputs: chosen-os: required: true type: choice options: - Ubuntu - macOS jobs: test: runs-on: [self-hosted, "${{ inputs.chosen-os }}"] steps: - run: echo Hello world! ``` - 여러 머신에서 워크플로를 실행하려면 [`jobs..strategy`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategy)를 사용합니다. > \[!NOTE] > `self-hosted`와 같은 단순한 문자열에는 따옴표가 필요하지 않지만, `"${{ inputs.chosen-os }}"`와 같은 식에는 따옴표가 필수입니다. ### GitHub 호스팅 실행기 선택 GitHub에서 호스트되는 실행기를 사용하는 경우 각 작업은 `runs-on`으로 지정된 실행기 이미지의 새 인스턴스에서 실행됩니다. GitHub 호스트형 실행기를 사용하는 경우 실행기의 값은 실행기 레이블 또는 실행기 그룹의 이름입니다. 표준 GitHub 호스트형 실행기 레이블은 다음 표에 나와 있습니다. 자세한 내용은 [GitHub 호스팅 실행기](/ko/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners)을(를) 참조하세요. ### 공개 리포지토리용 표준 GitHub-호스티드 러너. 공용 리포지토리의 경우 아래 표에 표시된 워크플로 레이블을 사용하는 작업은 관련 사양으로 실행됩니다. 단일 CPU 실행기를 제외하고, 각 GitHub에서 호스팅되는 실행기는 GitHub에 의해 호스트되는 새 VM(가상 머신)입니다. 단일 CPU 실행기는 공유 가상 머신의 컨테이너에서 호스팅됩니다. [GitHub 호스팅 실행기 참조](/ko/actions/reference/runners/github-hosted-runners#single-cpu-runners)을 참조하세요. 공개 리포지토리에서는 표준 GitHub-호스티드 러너를 무료로 무제한 사용할 수 있습니다. ```
가상 머신/컨테이너 프로세서 (CPU) 메모리 (RAM) 스토리지 (SSD) 아키텍처 Workflow 레이블
Linux 1 5 GB 14 GB x64 ubuntu-slim
Linux 4 16GB 14GB x64 ``` ubuntu-latest, , ubuntu-24.04ubuntu-22.04
Windows 4 16GB 14GB x64 windows-latest, windows-2025, windows-2025-vs2026 (공개 미리 보기), windows-2022
Linux 4 16GB 14GB arm64 ubuntu-24.04-arm, ubuntu-22.04-arm
Windows 4 16GB 14GB arm64 windows-11-arm
macOS 4 14GB 14GB Intel macos-15-intel, macos-26-intel
macOS 3(M1) 7GB 14GB arm64 macos-latest, macos-14, macos-15macos-26
### 프라이빗 리포지토리에 대한 표준 GitHub 호스팅 실행기. 비공개 리포지토리의 경우, 아래 표에 표시된 Workflow 레이블을 사용하는 작업은 해당 사양의 가상 머신에서 실행됩니다. 이 러너는 GitHub 계정에 할당된 무료 사용 시간을 사용하며, 이후에는 분당 요율로 청구됩니다. [작업 실행기 요금](/ko/billing/reference/actions-minute-multipliers)을(를) 참조하세요. ```
가상 머신 프로세서 (CPU) 메모리 (RAM) 스토리지 (SSD) 아키텍처 Workflow 레이블
Linux 1 5 GB 14 GB x64 ubuntu-slim
Linux 2 8GB 14GB x64 ``` ubuntu-latest, , ubuntu-24.04ubuntu-22.04
Windows 2 8GB 14GB x64 windows-latest, , windows-2025windows-2022
Linux 2 8GB 14GB arm64 ubuntu-24.04-arm, ubuntu-22.04-arm
Windows 2 8GB 14GB arm64 windows-11-arm
macOS 4 14GB 14GB Intel macos-15-intel, macos-26-intel
macOS 3(M1) 7GB 14GB arm64 macos-latest, macos-14, macos-15macos-26
표준 GitHub 호스트형 실행기 외에도 GitHub은(는) GitHub Team 및 GitHub Enterprise Cloud 플랜 고객에게 더 많은 코어와 디스크 공간, GPU 지원 머신, ARM 지원 머신 등 고급 기능을 갖춘 다양한 관리형 가상 머신을 제공합니다. 자세한 내용은 [더 큰 주자들](/ko/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners)을(를) 참조하세요. > \[!NOTE] > `-latest` 실행기 이미지는 GitHub에서 제공하는 안정적인 최신 이미지이며 운영 체제 공급업체에서 사용할 수 있는 운영 체제의 최신 버전이 아닐 수도 있습니다. > \[!WARNING] > 베타 및 사용되지 않는 이미지는 "있는 그대로" "모든 오류를 포함하여" "사용 가능한 상태로" 제공되며, 서비스 수준 계약 및 보증에서 제외됩니다. 베타 이미지는 고객 지원에서 다루지 않을 수 있습니다. #### 예제: 운영 체제 지정 ```yaml runs-on: ubuntu-latest ``` 자세한 내용은 [GitHub 호스팅 실행기](/ko/actions/using-github-hosted-runners/about-github-hosted-runners)을(를) 참조하세요. ### 자체 호스팅 실행기 선택 작업에 대한 자체 호스팅 실행기를 지정하려면 자체 호스팅 실행기 레이블을 사용하여 워크플로 파일에서 `runs-on`을 구성합니다. 자체 호스팅 실행기에는 `self-hosted` 레이블이 있을 수 있습니다. 자체 호스트형 실행기를 설정할 때 기본적으로 `self-hosted` 레이블이 포함됩니다. 자체 호스트형 레이블이 적용되지 않도록 `--no-default-labels` 플래그를 전달할 수 있습니다. 레이블은 운영 체제 또는 아키텍처와 같은 실행기에 대한 타겟팅 옵션을 만드는 데 사용할 수 있으며, `self-hosted`로 시작하는 레이블 배열(먼저 나열해야 함)을 제공한 다음 필요에 따라 추가 레이블을 포함하는 것이 좋습니다. 레이블 배열을 지정하면 지정한 모든 레이블이 있는 실행기에서 작업이 큐에 대기됩니다. > \[!NOTE] Actions Runner Controller는 `self-hosted` 레이블을 지원하지 않습니다. #### 예제: 실행기 선택에 레이블 사용 ```yaml runs-on: [self-hosted, linux] ``` 자세한 내용은 [자체 호스팅 실행기](/ko/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners) 및 [워크플로에서 자체 호스트형 런너 사용](/ko/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow)을(를) 참조하세요. ### 그룹 내에서 실행기 선택 실행기 그룹을 대상으로 지정하여 해당 그룹의 멤버인 모든 실행기에서 작업이 실행되도록 `runs-on`을(를) 사용할 수 있습니다. 보다 세분화된 컨트롤을 위해 실행기 그룹을 레이블과 결합할 수 있습니다. 실행기 그룹에는 [더 큰 실행기](/ko/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners) 또는 [자체 호스팅 실행기](/ko/actions/how-tos/managing-self-hosted-runners)만 구성원으로 사용할 수 있습니다. #### 예시: 그룹을 사용하여 작업 실행 위치 제어 이 예제에서는 Ubuntu 실행기라는 `ubuntu-runners` 그룹에 추가되었습니다. `runs-on` 키는 `ubuntu-runners` 그룹에서 사용 가능한 모든 실행기로 작업을 보냅니다. ```yaml name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: group: ubuntu-runners steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v4 with: node-version: '14' - run: npm install -g bats - run: bats -v ``` #### 예시: 그룹 및 레이블 결합 그룹과 레이블을 결합할 때, 러너는 작업을 실행할 수 있는 자격을 얻기 위해 두 가지 요구 사항을 모두 충족해야 합니다. 이 예제에서 `ubuntu-runners` 실행기 그룹은 Ubuntu 실행기들로 구성되어 있으며, 각 실행기에는 `ubuntu-24.04-16core` 레이블이 부여되어 있습니다. `runs-on` 키가 `group`, `labels`와 결합되어 작업이 일치하는 레이블이 있는 그룹 내에서 사용 가능한 모든 실행기로 라우팅됩니다. ```yaml name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: group: ubuntu-runners labels: ubuntu-24.04-16core steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v4 with: node-version: '14' - run: npm install -g bats - run: bats -v ``` ## `jobs..snapshot` 사용자 지정 이미지를 생성하는 데 사용할 `jobs..snapshot` 수 있습니다. ``` [사용자 지정 이미지 생성](/actions/how-tos/manage-runners/larger-runners/use-custom-images#generating-a-custom-image)에 표시된 것처럼 문자열 구문 또는 매핑 구문을 사용하여 스냅샷 키워드를 작업에 추가합니다. ``` 스냅샷 키워드를 포함하는 각 작업은 별도의 이미지를 만듭니다. 하나의 이미지 또는 이미지 버전만 생성하려면 모든 워크플로 단계를 단일 작업에 포함합니다. 스냅샷 키워드를 포함하는 작업의 각 성공적인 실행은 해당 이미지의 새 버전을 만듭니다. 자세한 내용은 [사용자 지정 이미지 사용](/ko/actions/how-tos/manage-runners/larger-runners/use-custom-images)을(를) 참조하세요. ## `jobs..environment` `jobs..environment`를 사용하여 작업에서 참조하는 환경을 정의합니다. 환경을 환경 `name`만으로 제공하거나 `name` 및 `url`을 사용하여 환경 개체로 제공할 수 있습니다. URL은 배포 API에서 `environment_url`에 매핑됩니다. 배포 API에 대한 자세한 내용은 [리포지토리에 대한 REST API 엔드포인트](/ko/rest/repos#deployments)을(를) 참조하세요. > \[!NOTE] > 환경을 참조하는 작업이 실행기로 전송되기 전에 모든 배포 보호 규칙이 전달되어야 합니다. 자세한 내용은 [배포 환경 관리](/ko/actions/deployment/targeting-different-environments/managing-environments-for-deployment)을(를) 참조하세요. ### 예: 단일 환경 이름 사용 ```yaml environment: staging_environment ``` ### 예: 환경 이름 및 URL 사용 ```yaml environment: name: production_environment url: https://github.com ``` `url`의 값은 식이 될 수 있습니다. 허용되는 언어 식 컨텍스트: [`github`](/ko/actions/learn-github-actions/contexts#github-context), [`inputs`](/ko/actions/learn-github-actions/contexts#inputs-context), [`vars`](/ko/actions/learn-github-actions/contexts#vars-context), [`needs`](/ko/actions/learn-github-actions/contexts#needs-context), [`strategy`](/ko/actions/learn-github-actions/contexts#strategy-context), [`matrix`](/ko/actions/learn-github-actions/contexts#matrix-context), [`job`](/ko/actions/learn-github-actions/contexts#job-context), [`runner`](/ko/actions/learn-github-actions/contexts#runner-context), [`env`](/ko/actions/learn-github-actions/contexts#env-context) 및 [`steps`](/ko/actions/learn-github-actions/contexts#steps-context). 식에 대한 자세한 내용은 [워크플로 및 작업에서 식 평가](/ko/actions/learn-github-actions/expressions)을(를) 참조하세요. ### 예: 출력을 URL로 사용 ```yaml environment: name: production_environment url: ${{ steps.step_id.outputs.url_output }} ``` `name`의 값은 식이 될 수 있습니다. 허용되는 언어 식 컨텍스트: [`github`](/ko/actions/learn-github-actions/contexts#github-context), [`inputs`](/ko/actions/learn-github-actions/contexts#inputs-context), [`vars`](/ko/actions/learn-github-actions/contexts#vars-context), [`needs`](/ko/actions/learn-github-actions/contexts#needs-context), [`strategy`](/ko/actions/learn-github-actions/contexts#strategy-context), [`matrix`](/ko/actions/learn-github-actions/contexts#matrix-context). 식에 대한 자세한 내용은 [워크플로 및 작업에서 식 평가](/ko/actions/learn-github-actions/expressions)을(를) 참조하세요. ### 예: 환경 이름을 식으로 사용 ```yaml environment: name: ${{ github.ref_name }} ``` ## `jobs..concurrency` `jobs..concurrency`를 사용하여 동일한 동시성 그룹을 사용하는 단일 작업 또는 워크플로만 한 번에 실행되도록 할 수 있습니다. 동시성 그룹은 모든 문자열 또는 식일 수 있습니다. 허용되는 언어 식 컨텍스트: [`github`](/ko/actions/learn-github-actions/contexts#github-context), [`inputs`](/ko/actions/learn-github-actions/contexts#inputs-context), [`vars`](/ko/actions/learn-github-actions/contexts#vars-context), [`needs`](/ko/actions/learn-github-actions/contexts#needs-context), [`strategy`](/ko/actions/learn-github-actions/contexts#strategy-context), [`matrix`](/ko/actions/learn-github-actions/contexts#matrix-context). 식에 대한 자세한 내용은 [워크플로 및 작업에서 식 평가](/ko/actions/learn-github-actions/expressions)을(를) 참조하세요. 워크플로 수준에서 `concurrency`를 지정할 수도 있습니다. 자세한 내용은 [`concurrency`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#concurrency)를 참조하세요. 다시 말해 동시성 그룹 하나에는 한 번에 실행 중인 작업 최대 한 개, 보류 중인 작업 최대 한 개만 있을 수 있습니다. 동시 작업 또는 워크플로가 큐에 대기 중인 경우 리포지토리의 동일한 동시성 그룹을 사용하는 다른 작업 또는 워크플로가 진행 중이면 대기 중인 작업 또는 워크플로는 `pending` 상태가 됩니다. 동일한 동시성 그룹에 있는 모든 기존 `pending` 작업 또는 워크플로가 있는 경우 취소되고 대기 중인 새 작업 또는 워크플로가 대신 수행됩니다. 동일한 동시성 그룹에서 현재 실행 중인 작업 또는 워크플로도 취소하려면 `cancel-in-progress: true`를 지정합니다. 동일한 동시성 그룹에서 현재 실행 중인 작업이나 워크플로를 조건부 취소하려면, 허용된 모든 식 컨텍스트에서 `cancel-in-progress`을(를) 식으로 지정하면 됩니다. > \[!NOTE] > > * 동시성 그룹 이름은 대/소문자를 구분하지 않습니다. 예를 들어 `prod` 및 `Prod`는 동일한 동시성 그룹으로 처리됩니다. > * 동시성 그룹을 사용하는 작업 또는 워크플로 실행에 대해서는 순서가 보장되지 않습니다. 동일한 동시성 그룹에서 작업 또는 워크플로 실행은 임의의 순서로 처리됩니다. ### 예: 동시성 및 기본 동작 사용 GitHub Actions의 기본 동작은 여러 작업 또는 워크플로 실행이 동시에 실행되도록 하는 것입니다. `concurrency` 키워드를 사용하면 워크플로 실행의 동시성을 제어할 수 있습니다. 예를 들어 트리거 조건이 정의된 직후에 `concurrency` 키워드를 사용하면 특정 분기에 대한 전체 워크플로 실행의 동시성을 제한할 수 있습니다. ```yaml on: push: branches: - main concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` 작업 수준에서 `concurrency` 키워드를 사용하여 워크플로 내에서 작업의 동시성을 제한할 수도 있습니다. ```yaml on: push: branches: - main jobs: job-1: runs-on: ubuntu-latest concurrency: group: example-group cancel-in-progress: true ``` ### 예: 동시성 그룹 동시성 그룹은 워크플로 실행 또는 동일한 동시성 키를 공유하는 작업의 실행을 관리하고 제한하는 방법을 제시합니다. 이 `concurrency` 키는 워크플로 또는 작업을 함께 동시성 그룹으로 그룹화하는 데 사용됩니다. `concurrency` 키를 정의할 때 GitHub Actions은(는) 지정된 시간에 해당 키를 가진 하나의 워크플로 또는 작업만 실행되도록 합니다. 새 워크플로가 실행되거나 작업이 동일한 `concurrency` 키로 시작하는 경우 GitHub Actions은(는) 해당 키로 이미 실행 중인 워크플로 또는 작업을 취소합니다. `concurrency` 키는 하드 코딩된 문자열이거나 컨텍스트 변수를 포함하는 동적 식일 수 있습니다. 워크플로 또는 작업이 동시성 그룹의 일부가 되도록 워크플로에서 동시성 조건을 정의할 수 있습니다. 즉, 워크플로 실행 또는 작업이 시작되면 GitHub는 동일한 동시성 그룹에서 이미 진행 중인 워크플로 실행 또는 작업을 취소합니다. 이는 충돌을 일으키거나 필요한 것보다 더 많은 리소스를 사용할 수 있는 작업을 방지하기 위해 스테이징 환경에 배포하는 데 사용되는 것과 같은 특정 워크플로 또는 작업 집합에 대한 병렬 실행을 방지하려는 시나리오에서 유용합니다. 이 예제에서 `job-1`은 이름이 `staging_environment`인 동시성 그룹의 일부입니다. 즉, 새로 실행된 `job-1`이 트리거되면 `staging_environment` 동시성 그룹에서 이미 진행 중인 동일한 작업의 실행이 취소됩니다. ```yaml jobs: job-1: runs-on: ubuntu-latest concurrency: group: staging_environment cancel-in-progress: true ``` 또는 워크플로에서 동적 식(예: `concurrency: ci-${{ github.ref }}`)을 사용하면 워크플로 또는 작업이 워크플로를 트리거한 분기 또는 태그의 참조 앞에 이름이 `ci-`인 동시성 그룹의 일부가 됩니다. 이 예제에서는 이전 실행이 진행 중인 동안 새 커밋이 기본 분기에 푸시되면 이전 실행이 취소되고 새 커밋이 시작됩니다. ```yaml on: push: branches: - main concurrency: group: ci-${{ github.ref }} cancel-in-progress: true ``` ### 예: 동시성을 사용하여 진행 중인 작업 또는 실행 취소 동시성을 사용하여 GitHub Actions에서 진행 중인 작업 또는 실행을 취소하려면 `true`로 설정된 `cancel-in-progress` 옵션을 통해 `concurrency` 키를 사용할 수 있습니다. ```yaml concurrency: group: ${{ github.ref }} cancel-in-progress: true ``` 이 예제에서는 특정 동시성 그룹을 정의하지 않고 GitHub Actions은(는) 진행 중인 *모든* 작업 또는 워크플로 실행을 취소합니다. ### 예: 대체 값 사용 특정 이벤트에 대해서만 정의되는 속성으로 그룹 이름을 빌드하는 경우 대체 값을 사용할 수 있습니다. 예를 들어 `github.head_ref`는 `pull_request` 이벤트에서만 정의됩니다. 워크플로가 `pull_request` 이벤트 외에 다른 이벤트에도 응답하는 경우 구문 오류를 방지하기 위해 대체를 제공해야 합니다. 다음 동시성 그룹은 `pull_request` 이벤트에서만 진행 중인 작업 또는 실행을 취소합니다. `github.head_ref`가 정의되지 않은 경우 동시성 그룹은 실행에 고유하고 정의된 실행 ID로 대체됩니다. ```yaml concurrency: group: ${{ github.head_ref || github.run_id }} cancel-in-progress: true ``` ### 예: 현재 워크플로에 대해서만 진행 중인 작업 또는 실행 취소 동일한 리포지토리에 여러 워크플로가 있는 경우 다른 워크플로에서 진행 중인 작업 또는 실행이 취소되지 않도록 워크플로 전체에서 동시성 그룹 이름이 고유해야 합니다. 그렇지 않으면 워크플로에 관계없이 이전에 진행 중이거나 보류 중인 작업이 취소됩니다. 동일한 워크플로의 진행 중인 실행만 취소하기 위해 `github.workflow` 속성을 사용하여 동시성 그룹을 빌드할 수 있습니다. ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` ### 예: 특정 분기에서 진행 중인 작업만 취소 특정 분기에서 진행 중인 작업만 취소하고 나머지는 취소하지 않고자 하는 경우, `cancel-in-progress`을(를) 포함한 조건식을 사용하면 됩니다. 예를 들어 개발 분기에서만 진행 중인 작업을 취소하고 릴리스 분기에서는 취소하지 않으려면 이렇게 하면 됩니다. 릴리스 분기에서 실행 중이 아닌 경우 같은 워크플로의 진행 중인 실행만 취소하려면, 다음과 비슷한 식에 대하여 `cancel-in-progress`을(를) 설정하면 됩니다. ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: ${{ !contains(github.ref, 'release/')}} ``` 이 예시에서는 `release/1.2.3` 분기에 대한 여러 푸시를 실행해도 진행 중인 실행을 취소하지 않습니다. `main`과(와) 같은 다른 분기로 푸시하면 진행 중인 실행이 취소됩니다. ## `jobs..outputs` `jobs..outputs`를 사용하여 작업 출력의 `map`을 만들 수 있습니다. 작업 출력은 이 작업에 의존하는 모든 다운스트림 작업에 사용할 수 있습니다. 작업 종속성 정의에 대한 자세한 내용은 [`jobs..needs`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds)를 참조하세요. 작업당 출력 크기는 최대 1MB입니다. 워크플로 실행의 모든 출력 합계는 최대 50MB가 될 수 있습니다. 크기는 UTF-16 인코딩을 기준으로 추정됩니다. 식을 포함하는 작업 출력은 각 작업의 끝에 있는 실행기에서 평가됩니다. 비밀이 포함된 출력은 실행기에서 수정되며 GitHub Actions로 보내지 않습니다. 출력에 비밀이 포함될 수 있으므로 “비밀이 포함될 수 있으므로 출력 `{output.Key}`를 건너뜁니다.”와 같은 경고 메시지가 표시됩니다. 비밀을 처리하는 방법에 대한 자세한 내용은 [예시: 작업 또는 워크플로 간에 비밀 마스킹 및 전달](/ko/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#example-masking-and-passing-a-secret-between-jobs-or-workflows)을 참조하세요. 종속 작업에서 작업 출력을 사용하려면 `needs` 컨텍스트를 사용할 수 있습니다. 자세한 내용은 [문맥 참조](/ko/actions/learn-github-actions/contexts#needs-context)을(를) 참조하세요. ### 예: 작업 출력 정의 ```yaml jobs: job1: runs-on: ubuntu-latest # Map a step output to a job output outputs: output1: ${{ steps.step1.outputs.test }} output2: ${{ steps.step2.outputs.test }} steps: - id: step1 run: echo "test=hello" >> "$GITHUB_OUTPUT" - id: step2 run: echo "test=world" >> "$GITHUB_OUTPUT" job2: runs-on: ubuntu-latest needs: job1 steps: - env: OUTPUT1: ${{needs.job1.outputs.output1}} OUTPUT2: ${{needs.job1.outputs.output2}} run: echo "$OUTPUT1 $OUTPUT2" ``` ### 행렬형 작업에서 작업 출력 사용 행렬형은 서로 다른 이름의 여러 출력을 생성하는 데 사용할 수 있습니다. 행렬형을 사용하는 경우 행렬형 내의 모든 작업에서 작업 출력이 결합됩니다. ```yaml jobs: job1: runs-on: ubuntu-latest outputs: output_1: ${{ steps.gen_output.outputs.output_1 }} output_2: ${{ steps.gen_output.outputs.output_2 }} output_3: ${{ steps.gen_output.outputs.output_3 }} strategy: matrix: version: [1, 2, 3] steps: - name: Generate output id: gen_output run: | version="${{ matrix.version }}" echo "output_${version}=${version}" >> "$GITHUB_OUTPUT" job2: runs-on: ubuntu-latest needs: [job1] steps: # Will show # { # "output_1": "1", # "output_2": "2", # "output_3": "3" # } - run: echo '${{ toJSON(needs.job1.outputs) }}' ``` > \[!WARNING] > 작업은 행렬형 작업이 실행되는 순서를 보장하지 않습니다. 출력 이름이 고유한지 확인하고, 그렇지 않으면 실행되는 마지막 행렬형 작업이 출력 값을 재정의합니다. ## `jobs..env` 작업의 모든 단계에서 사용할 수 있는 `map` 변수. 전체 워크플로 또는 개별 단계에 변수를 설정할 수도 있습니다. 자세한 내용은 [`env`](#env) 및 [`jobs..steps[*].env`](#jobsjob_idstepsenv)을(를) 참조하세요. 둘 이상의 변수가 동일한 이름으로 정의되면 GitHub는 가장 구체적인 환경 변수를 사용합니다. 예를 들어 단계에 정의된 환경 변수는 단계가 실행되는 동안 동일한 이름의 작업 및 워크플로 환경 변수를 재정의합니다. 작업에 정의된 환경 변수는 작업이 실행되는 동안 동일한 이름의 워크플로 변수를 재정의합니다. ### ``` `jobs..env`의 예 ``` ```yaml jobs: job1: env: FIRST_NAME: Mona ``` ## `jobs..defaults` `jobs..defaults`를 사용하여 작업의 모든 단계에 적용할 기본 설정의 `map`을 만듭니다. 전체 워크플로에 대한 기본 설정을 지정할 수도 있습니다. 자세한 내용은 [`defaults`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#defaults)를 참조하세요. 둘 이상의 기본 설정이 동일한 이름으로 정의되면 GitHub는 가장 구체적인 기본 설정을 사용합니다. 예를 들어 작업에 정의된 기본 설정은 워크플로에 정의된 이름과 동일한 기본 설정을 재정의합니다. ## `jobs..defaults.run` `jobs..defaults.run`을(를) 사용하여 작업의 모든 `run` 단계에 기본값 `shell` 및 `working-directory`를 제공합니다. 작업의 모든 [`run`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) 단계에 기본 `shell`및`working-directory` 옵션을 제공할 수 있습니다. 전체 워크플로에 대한 `run`의 기본 설정을 지정할 수도 있습니다. 자세한 내용은 [`defaults.run`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun)를 참조하세요. 이러한 경고는 `jobs..defaults.run` 및 `jobs..steps[*].run` 수준에서 재정의할 수 있습니다. 둘 이상의 기본 설정이 동일한 이름으로 정의되면 GitHub는 가장 구체적인 기본 설정을 사용합니다. 예를 들어 작업에 정의된 기본 설정은 워크플로에 정의된 이름과 동일한 기본 설정을 재정의합니다. ## `jobs..defaults.run.shell` `shell`을(를) 사용하여 단계의 `shell`을(를) 정의합니다. 키워드는 여러 컨텍스트를 참조할 수 있습니다. 자세한 내용은 [컨텍스트](/ko/actions/learn-github-actions/contexts#context-availability)를 참조하세요. | 지원되는 플랫폼 | `shell` 매개 변수 | 설명 | 내부적으로 명령 실행 | | ------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | Linux / macOS | unspecified | 비 Windows 플랫폼의 기본 셸입니다. `bash`가 명시적으로 지정된 경우와는 다른 명령을 실행한다는 점에 유의하세요. `bash`를 경로에서 찾을 수 없는 경우, `sh`로 처리됩니다. | `bash -e {0}` | | 모두 | `bash` | `sh`로의 대체가 있는 비 Windows 플랫폼의 기본 셸입니다. Windows에서 bash 셸을 지정할 때 Windows용 Git에 포함된 bash 셸이 사용됩니다. | `bash --noprofile --norc -eo pipefail {0}` | | 모두 | `pwsh` | PowerShell Core입니다. GitHub가 스크립트 이름에 `.ps1` 확장을 추가합니다. | `pwsh -command ". '{0}'"` | | 모두 | `python` | Python 명령을 실행합니다. | `python {0}` | | Linux / macOS | `sh` | 셸이 제공되지 않고 경로에 `bash`가 없는 경우 비 Windows 플랫폼에 대한 대체 동작입니다. | `sh -e {0}` | | Windows | `cmd` | GitHub는 스크립트 이름에 `.cmd` 확장을 추가하고 `{0}`로 대체합니다. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. | | Windows | `pwsh` | Windows에서 사용되는 기본 셸입니다. PowerShell Core입니다. GitHub가 스크립트 이름에 `.ps1` 확장을 추가합니다. 자체 호스팅 Windows 실행기에 \_PowerShell Core\_가 설치되어 있지 않으면 \_PowerShell Desktop\_이 대신 사용됩니다. | `pwsh -command ". '{0}'"`. | | Windows | `powershell` | PowerShell 데스크톱입니다. GitHub가 스크립트 이름에 `.ps1` 확장을 추가합니다. | `powershell -command ". '{0}'"`. | 둘 이상의 기본 설정이 동일한 이름으로 정의되면 GitHub는 가장 구체적인 기본 설정을 사용합니다. 예를 들어 작업에 정의된 기본 설정은 워크플로에 정의된 이름과 동일한 기본 설정을 재정의합니다. ## `jobs..defaults.run.working-directory` `working-directory`을(를) 사용하여 단계의 `shell`에 대한 작업 디렉터리를 정의합니다. 키워드는 여러 컨텍스트를 참조할 수 있습니다. 자세한 내용은 [컨텍스트](/ko/actions/learn-github-actions/contexts#context-availability)를 참조하세요. > \[!TIP] > 셸을 실행하기 전에 할당한 `working-directory`가 실행기에 존재하는지 확인합니다. > 둘 이상의 기본 설정이 동일한 이름으로 정의되면 GitHub는 가장 구체적인 기본 설정을 사용합니다. 예를 들어 작업에 정의된 기본 설정은 워크플로에 정의된 이름과 동일한 기본 설정을 재정의합니다. ### 예: 작업에 대한 기본 `run` 단계 옵션 설정 ```yaml jobs: job1: runs-on: ubuntu-latest defaults: run: shell: bash working-directory: ./scripts ``` ## `jobs..steps` 작업에는 `steps`라는 일련의 작업이 포함됩니다. 단계에 따라 퍼블릭 리포지토리에서 명령을 실행하거나, 설치 작업을 실행하거나, 또는 Docker 레지스트리에 게시된 작업에서 작업을 실행할 수 있습니다. 모든 단계가 작업을 실행하는 것은 아니지만 모든 작업은 한 단계로 실행됩니다. 각 단계는 실행기 환경에서 자체 프로세스로 실행되며 작업 영역 및 파일 시스템에 액세스할 수 있습니다. 단계가 자체 프로세스에서 실행되므로 여러 단계 간에는 환경 변수에 대한 변경 내용이 유지되지 않습니다. GitHub 에서는 작업을 설정하고 완료하는 기본 제공 단계를 제공합니다. ``` GitHub 처음 1,000개의 검사만 표시합니다. 그러나 워크플로 사용량 한도 내에 있는 한 무제한의 단계를 실행할 수 있습니다. 자세한 내용은 GitHub 호스트 실행기에 대한 [AUTOTITLE](/actions/learn-github-actions/usage-limits-billing-and-administration)과 자체 호스트 실행기 사용 제한에 대한 [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners)을 참조하세요. ``` ### ``` `jobs..steps`의 예 ``` ```yaml name: Greeting from Mona on: push jobs: my-job: name: My Job runs-on: ubuntu-latest steps: - name: Print a greeting env: MY_VAR: Hi there! My name is FIRST_NAME: Mona MIDDLE_NAME: The LAST_NAME: Octocat run: | echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME. ``` ## `jobs..steps[*].id` 단계의 고유 식별자입니다. `id`를 사용하여 컨텍스트에서 단계를 참조할 수 있습니다. 자세한 내용은 [문맥 참조](/ko/actions/learn-github-actions/contexts)을(를) 참조하세요. ## `jobs..steps[*].if` ```` `if` 조건을 사용하여 조건이 충족되지 않는 한 단계가 실행되지 않도록 할 수 있습니다. 지원되는 컨텍스트 및 식을 사용하여 조건을 만들 수 있습니다. 이 키에서 지원되는 컨텍스트에 대한 자세한 내용은 [AUTOTITLE](/actions/learn-github-actions/contexts#context-availability)을(를) 참조하세요. `if` 조건에서 식을 사용하는 경우, 선택에 따라 식 구문(`${{ }}`)을 생략해도 됩니다. GitHub Actions에서 자동으로 `if` 조건을 식으로 평가하기 때문입니다. 그러나, 이 예외는 어디에나 적용되지는 않습니다. `${{ }}` 식 구문을 사용하거나 `!`이 YAML 형식으로 예약된 표기법이므로 `!` 식이 시작될 때 항상 `''`, `""`, `()` 이스케이프를 사용해야 합니다. 예시: ```yaml if: ${{ ! startsWith(github.ref, 'refs/tags/') }} ``` 자세한 내용은 [AUTOTITLE](/actions/learn-github-actions/expressions)을 참조하세요. ```` ### 예제: 컨텍스트 사용 이 단계는 이벤트 유형이 `pull_request`이고 이벤트 작업이 `unassigned`인 경우에만 실행됩니다. ```yaml steps: - name: My first step if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }} run: echo This event is a pull request that had an assignee removed. ``` ### 예제: 상태 검사 함수 사용 ``` `my backup step`은 작업의 이전 단계가 실패할 때만 실행됩니다. 자세한 내용은 [AUTOTITLE](/actions/learn-github-actions/expressions#status-check-functions)을(를) 참조하세요. ``` ```yaml steps: - name: My first step uses: octo-org/action-name@main - name: My backup step if: ${{ failure() }} uses: actions/heroku@1.0.0 ``` ### 예제: 비밀 사용 비밀은 `if:` 조건에서 직접 참조할 수 없습니다. 대신 비밀을 작업 수준 환경 변수로 설정한 다음 환경 변수를 참조하여 작업의 단계를 조건부로 실행하는 것이 좋습니다. 비밀을 설정하지 않은 경우 예제와 같이 `${{ secrets.SuperSecret }}` 비밀을 참조하는 식의 반환 값은 빈 문자열이 됩니다. ```yaml name: Run a step if a secret has been set on: push jobs: my-jobname: runs-on: ubuntu-latest env: super_secret: ${{ secrets.SuperSecret }} steps: - if: ${{ env.super_secret != '' }} run: echo 'This step will only run if the secret has a value set.' - if: ${{ env.super_secret == '' }} run: echo 'This step will only run if the secret does not have a value set.' ``` 자세한 내용은 [문맥 참조](/ko/actions/learn-github-actions/contexts#context-availability) 및 [GitHub Actions에서 비밀 사용](/ko/actions/security-guides/using-secrets-in-github-actions)을(를) 참조하세요. ## `jobs..steps[*].name` ``` GitHub에 표시할 단계의 이름입니다. ``` ## `jobs..steps[*].uses` 작업 단계의 일부로 실행할 작업을 선택합니다. 작업은 재사용 가능한 코드 단위입니다. 워크플로와 동일한 리포지토리, 퍼블릭 리포지토리 또는 [게시된 Docker 컨테이너 이미지](https://hub.docker.com/)에 정의된 작업을 사용할 수 있습니다. Git 참조, SHA 또는 Docker 태그를 지정하여 사용 중인 작업의 버전을 포함하는 것이 좋습니다. 버전을 지정하지 않으면 작업 소유자가 업데이트를 게시할 때 워크플로가 중단되거나 예기치 않은 동작이 발생할 수 있습니다. * 릴리스된 작업 버전의 커밋 SHA를 사용하는 것이 안정성 및 보안 측면에서 가장 안전합니다. * 작업이 주 버전 태그를 게시하는 경우 호환성을 유지하면서 중요한 수정 및 보안 패치를 받아야 합니다. 이 동작은 작업 작성자의 재량에 따라 결정됩니다. * 작업의 기본 분기를 사용하는 것이 편리할 수 있지만 다른 사용자가 호환성이 손상되는 변경으로 새 주 버전을 릴리스하는 경우 워크플로가 중단될 수 있습니다. 일부 작업에는 [`with`](#jobsjob_idstepswith) 키워드를 사용하여 설정해야 하는 입력이 필요합니다. 작업의 추가 정보 파일을 검토하여 필요한 입력을 확인합니다. 작업은 JavaScript 파일 또는 Docker 컨테이너입니다. 사용 중인 작업이 Docker 컨테이너인 경우 Linux 환경에서 작업을 실행해야 합니다. 자세한 내용은 [`runs-on`](#jobsjob_idruns-on)을(를) 참조하세요. ### 예제: 버전이 지정된 작업 사용 ```yaml steps: # Reference a specific commit - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3 # Reference the major version of a release - uses: actions/checkout@v6 # Reference a specific version - uses: actions/checkout@v6.2.0 # Reference a branch - uses: actions/checkout@main ``` ### 예제: 퍼블릭 작업 사용 `{owner}/{repo}@{ref}` 공용 GitHub 리포지토리에서 분기, ref 또는 SHA를 지정할 수 있습니다. ```yaml jobs: my_first_job: steps: - name: My first step # Uses the default branch of a public repository uses: actions/heroku@main - name: My second step # Uses a specific version tag of a public repository uses: actions/aws@v2.0.1 ``` ### 예제: 하위 디렉터리에서 퍼블릭 작업 사용 `{owner}/{repo}/{path}@{ref}` 특정 브랜치, ref 또는 SHA의 공용 GitHub 저장소에 있는 하위 디렉터리입니다. ```yaml jobs: my_first_job: steps: - name: My first step uses: actions/aws/ec2@main ``` ### 예제: 워크플로와 동일한 리포지토리에서 작업 사용 `./path/to/dir` 워크플로 리포지토리의 작업이 포함된 디렉터리의 경로입니다. 작업을 사용하기 전에 리포지토리를 체크 아웃해야 합니다. 리포지토리 파일 구조 예시: ```shell |-- hello-world (repository) | |__ .github | └── workflows | └── my-first-workflow.yml | └── actions | |__ hello-world-action | └── action.yml ``` 경로는 기본 작업 디렉터리(`github.workspace`, `$GITHUB_WORKSPACE`)에 대해 상대적(`./`) 경로입니다. 작업이 리포지토리를 워크플로와 다른 위치로 검사하는 경우 로컬 작업에 사용되는 상대 경로를 업데이트해야 합니다. 워크플로 파일 예시: ```yaml jobs: my_first_job: runs-on: ubuntu-latest steps: # This step checks out a copy of your repository. - name: My first step - check out repository uses: actions/checkout@v6 # This step references the directory that contains the action. - name: Use local hello-world-action uses: ./.github/actions/hello-world-action ``` ### 예제: Docker Hub 작업 사용 `docker://{image}:{tag}` ``` [Docker Hub](https://hub.docker.com/)에 게시된 Docker 이미지입니다. ``` ```yaml jobs: my_first_job: steps: - name: My first step uses: docker://alpine:3.8 ``` ### 예: 다음을 사용 GitHub PackagesContainer registry `docker://{host}/{image}:{tag}` GitHub PackagesContainer registry에 있는 공용 Docker 이미지입니다. ```yaml jobs: my_first_job: steps: - name: My first step uses: docker://ghcr.io/OWNER/IMAGE_NAME ``` ### 예제: Docker 퍼블릭 레지스트리 작업 사용 `docker://{host}/{image}:{tag}` 퍼블릭 레지스트리의 Docker 이미지입니다. 이 예제에서는 `gcr.io`에서 Google Container Registry를 사용합니다. ```yaml jobs: my_first_job: steps: - name: My first step uses: docker://gcr.io/cloud-builders/gradle ``` ### 예제: 워크플로와 다른 프라이빗 리포지토리 내에서 작업 사용 워크플로는 프라이빗 리포지토리를 체크 아웃하고 작업을 로컬로 참조해야 합니다. 토큰을 personal access token 생성하고 비밀로 추가합니다. 자세한 내용은 [개인용 액세스 토큰 관리](/ko/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) 및 [GitHub Actions에서 비밀 사용](/ko/actions/security-guides/using-secrets-in-github-actions)을(를) 참조하세요. 예제에서 `PERSONAL_ACCESS_TOKEN`을 비밀 이름으로 바꿉니다. ```yaml jobs: my_first_job: steps: - name: Check out repository uses: actions/checkout@v6 with: repository: octocat/my-private-repo ref: v1.0 token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} path: ./.github/actions/my-private-repo - name: Run my action uses: ./.github/actions/my-private-repo/my-action ``` GitHub App 대신 personal access token을 사용하며, personal access token 소유주가 떠나더라도 워크플로가 계속 실행되게 하는 방법도 있습니다. 자세한 내용은 [GitHub Actions 워크플로에서 GitHub 앱을 사용하여 인증된 API 요청 만들기](/ko/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow)을(를) 참조하세요. ## `jobs..steps[*].run` 운영 체제의 셸을 사용하여 21,000자를 초과하지 않는 명령줄 프로그램을 실행합니다. `name`을 입력하지 않으면 단계 이름은 기본적으로 `run` 명령에 지정된 텍스트로 설정됩니다. 명령은 기본적으로 로그인하지 않는 셸을 사용하여 실행됩니다. 다른 셸을 선택하고 명령을 실행하는 데 사용되는 셸을 사용자 지정할 수 있습니다. 자세한 내용은 [`jobs..steps[*].shell`](#jobsjob_idstepsshell)을(를) 참조하세요. 각 `run` 키워드는 실행기 환경의 새 프로세스 및 셸을 나타냅니다. 다중 선 명령을 제공하면 각 선이 동일한 셸에서 실행됩니다. 예를 들면 다음과 같습니다. * 단일 선 명령: ```yaml - name: Install Dependencies run: npm install ``` * 다중 선 명령: ```yaml - name: Clean install dependencies and build run: | npm ci npm run build ``` ## `jobs..steps[*].working-directory` ``` `working-directory` 키워드를 사용하여 명령을 실행할 위치의 작업 디렉터리를 지정할 수 있습니다. ``` ```yaml - name: Clean temp directory run: rm -rf * working-directory: ./temp ``` 또는 작업의 모든 `run` 단계나 전체 워크플로의 모든 `run` 단계에 대해 기본 작업 디렉터리를 지정할 수 있습니다. 자세한 내용은 [`defaults.run.working-directory`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunworking-directory) 및 [`jobs..defaults.run.working-directory`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunworking-directory)을(를) 참조하세요. 스크립트를 `run` 단계를 사용하여 실행할 수도 있습니다. 자세한 내용은 [워크플로에 스크립트 추가](/ko/actions/writing-workflows/choosing-what-your-workflow-does/adding-scripts-to-your-workflow)을(를) 참조하세요. ## `jobs..steps[*].shell` 실행기 운영 체제의 기본 셸 설정 및 작업의 기본값을 `shell` 키워드를 사용하여 재정의할 수 있습니다. 기본 제공 `shell` 키워드를 사용하거나 사용자 지정 셸 옵션 집합을 정의할 수 있습니다. 내부적으로 실행되는 셸 명령은 `run` 키워드에 지정된 명령이 포함된 임시 파일을 실행합니다. | 지원되는 플랫폼 | `shell` 매개 변수 | 설명 | 내부적으로 명령 실행 | | ------------- | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | Linux / macOS | unspecified | 비 Windows 플랫폼의 기본 셸입니다. `bash`가 명시적으로 지정된 경우와는 다른 명령을 실행한다는 점에 유의하세요. `bash`를 경로에서 찾을 수 없는 경우, `sh`로 처리됩니다. | `bash -e {0}` | | 모두 | `bash` | `sh`로의 대체가 있는 비 Windows 플랫폼의 기본 셸입니다. Windows에서 bash 셸을 지정할 때 Windows용 Git에 포함된 bash 셸이 사용됩니다. | `bash --noprofile --norc -eo pipefail {0}` | | 모두 | `pwsh` | PowerShell Core입니다. GitHub가 스크립트 이름에 `.ps1` 확장을 추가합니다. | `pwsh -command ". '{0}'"` | | 모두 | `python` | Python 명령을 실행합니다. | `python {0}` | | Linux / macOS | `sh` | 셸이 제공되지 않고 경로에 `bash`가 없는 경우 비 Windows 플랫폼에 대한 대체 동작입니다. | `sh -e {0}` | | Windows | `cmd` | GitHub는 스크립트 이름에 `.cmd` 확장을 추가하고 `{0}`로 대체합니다. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. | | Windows | `pwsh` | Windows에서 사용되는 기본 셸입니다. PowerShell Core입니다. GitHub가 스크립트 이름에 `.ps1` 확장을 추가합니다. 자체 호스팅 Windows 실행기에 \_PowerShell Core\_가 설치되어 있지 않으면 \_PowerShell Desktop\_이 대신 사용됩니다. | `pwsh -command ". '{0}'"`. | | Windows | `powershell` | PowerShell 데스크톱입니다. GitHub가 스크립트 이름에 `.ps1` 확장을 추가합니다. | `powershell -command ". '{0}'"`. | 또는 작업의 모든 `run` 단계나 전체 워크플로의 모든 `run` 단계에 대해 기본 셸을 지정할 수 있습니다. 자세한 내용은 [`defaults.run.shell`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunshell) 및 [`jobs..defaults.run.shell`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunshell)을(를) 참조하세요. ### 예제: Bash를 사용하여 스크립트 실행 ```yaml steps: - name: Display the path shell: bash run: echo $PATH ``` ### 예제: Windows를 사용하는 명령 실행`cmd` ```yaml steps: - name: Display the path shell: cmd run: echo %PATH% ``` ### 예제: PowerShell Core를 사용하는 명령 실행 ```yaml steps: - name: Display the path shell: pwsh run: echo ${env:PATH} ``` ### 예제: PowerShell Desktop을 사용하여 명령 실행 ```yaml steps: - name: Display the path shell: powershell run: echo ${env:PATH} ``` ### 예제: 인라인 Python 스크립트 실행 ```yaml steps: - name: Display the path shell: python run: | import os print(os.environ['PATH']) ``` ### 사용자 지정 셸 ``` `shell`를 사용하여 `command [options] {0} [more_options]` 값을 템플릿 문자열로 설정할 수 있습니다. GitHub 는 문자열의 첫 번째 공백으로 구분된 단어를 명령으로 해석하고 임시 스크립트의 파일 이름을 삽입 `{0}`합니다. ``` 예를 들면 다음과 같습니다. ```yaml steps: - name: Display the environment variables and their values shell: perl {0} run: | print %ENV ``` 이 예제에서 사용된 `perl` 명령을 실행기에 설치해야 합니다. GitHub 호스팅 실행기에서 포함된 소프트웨어에 대한 자세한 내용은 [GitHub 호스팅 실행기](/ko/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software)을 참조하세요. ### 종료 코드 및 오류 작업 기본 설정 기본 제공 셸 키워드의 경우 호스트된 GitHub실행기에서 실행되는 다음 기본값을 제공합니다. 셸 스크립트를 실행할 때는 해당 지침을 사용해야 합니다. * `bash` / `sh`: * 기본적으로 `set -e` 사용 장애 조치(fail-fast) 동작은 `sh` 및 `bash` 모두에 적용됩니다. `shell: bash`이(가) 지정되면 `-o pipefail` 또한 0이 아닌 종료 상태를 생성하는 파이프라인에서 조기 종료를 적용하기 위해 적용됩니다. * 셸 옵션에 템플릿 문자열을 제공하여 셸 매개 변수를 완전히 제어할 수 있습니다. 예: `bash {0}`. * `sh`와(과) 같은 셸은 스크립트에서 실행된 마지막 명령의 종료 코드를 통해 종료되며, 이는 작업에 대한 기본 동작이기도 합니다. 실행기는 이 종료 코드에 따라 단계의 상태를 실패/성공으로 보고합니다. * `powershell`/`pwsh` * 가능한 경우 빠른 페일 패스트 동작입니다. `pwsh` 및 기본 제공 `powershell` 셸의 경우 스크립트 내용 앞에 `$ErrorActionPreference = 'stop'` 추가됩니다. * 작업 상태가 스크립트의 마지막 종료 코드를 반영하도록 powershell 스크립트에 `if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE }`를 추가합니다. * 사용자는 항상 기본 제공 셸을 사용하지 않고 필요에 따라 `pwsh -File {0}` 또는 `powershell -Command "& '{0}'"`와 같은 사용자 지정 셸 옵션을 제공하여 옵트아웃할 수 있습니다. * `cmd` * 스크립트를 작성하여 각 오류 코드를 확인하고 그에 따라 응답하는 것 외에는 페일 패스트(Fail-fast) 동작에 완전히 옵트인하는 방법이 없는 것 같습니다. 기본적으로 이 동작을 실제로 제공할 수 없으므로 스크립트에 이 동작을 작성해야 합니다. * `cmd.exe`은(는) 실행한 마지막 프로그램의 오류 수준으로 종료되고 실행기에 오류 코드를 반환합니다. 이 동작은 내부적으로 이전 `sh` 및 `pwsh` 기본 동작과 일치하며 `cmd.exe` 기본값이므로 이 동작은 그대로 유지됩니다. ## `jobs..steps[*].with` 작업에 정의된 입력 매개 변수의 `map`입니다. 각 입력 매개 변수는 키/값 쌍입니다. 입력 매개 변수는 환경 변수로 설정됩니다. 변수가 `INPUT_`접두어로 추가되고 대문자로 변환됩니다. Docker 컨테이너에 대해 정의된 입력 매개 변수는 `args`을(를) 사용해야 합니다. 자세한 내용은 [`jobs..steps[*].with.args`](#jobsjob_idstepswithargs)을(를) 참조하세요. ### ``` `jobs..steps[*].with`의 예 `first_name` 작업에 정의된 세 개의 입력 매개 변수(`middle_name`, `last_name`, `hello_world`)를 정의합니다. 입력 변수는 `hello-world` 작업에서 `INPUT_FIRST_NAME`, `INPUT_MIDDLE_NAME`, `INPUT_LAST_NAME` 환경 변수에서 액세스할 수 있습니다. ``` ```yaml jobs: my_first_job: steps: - name: My first step uses: actions/hello_world@main with: first_name: Mona middle_name: The last_name: Octocat ``` ## `jobs..steps[*].with.args` Docker 컨테이너에 대한 입력을 정의하는 `string`입니다. GitHub 는 컨테이너가 시작할 때 `args` 을/를 그것의 `ENTRYPOINT` 에 전달합니다. 이 매개 변수는 `array of strings`를 지원하지 않습니다. 공백을 포함하는 단일 인수는 큰따옴표 `""`로 묶어야 합니다. ### ``` `jobs..steps[*].with.args`의 예 ``` ```yaml steps: - name: Explain why this job ran uses: octo-org/action-name@main with: entrypoint: /bin/echo args: The ${{ github.event_name }} event triggered this step. ``` ``` `args`는 `CMD`의 `Dockerfile` 명령 대신 사용됩니다. `CMD`에서 `Dockerfile`를 사용하는 경우 기본 설정에 따라 정렬된 지침을 사용합니다. ``` 1. 작업의 README에서 필요한 인수를 문서화하고 `CMD` 명령에서 생략합니다. 2. 어떤 `args`도 지정하지 않고 작업을 사용할 수 있는 기본값을 사용합니다. 3. 작업이 `--help` 플래그 또는 이와 유사한 항목을 노출하는 경우 이를 기본값으로 사용하여 작업을 자체 문서화합니다. ## `jobs..steps[*].with.entrypoint` ``` `ENTRYPOINT`의 Docker `Dockerfile`를 재정의하거나 아직 지정하지 않은 경우 설정합니다. 셸 및 exec 형식인 Docker `ENTRYPOINT` 명령과 달리 `entrypoint` 키워드는 실행될 실행 파일을 정의하는 단일 문자열만 허용합니다. ``` ### ``` `jobs..steps[*].with.entrypoint`의 예 ``` ```yaml steps: - name: Run a custom command uses: octo-org/action-name@main with: entrypoint: /a/different/executable ``` ``` `entrypoint` 키워드는 Docker 컨테이너 작업에 사용되어야 하지만 입력을 정의하지 않는 JavaScript 작업에 사용할 수도 있습니다. ``` ## `jobs..steps[*].env` 실행기 환경에서 사용할 단계에 대한 변수를 설정합니다. 전체 워크플로 또는 하나의 작업에 대해 변수를 설정할 수도 있습니다. 자세한 내용은 [`env`](#env) 및 [`jobs..env`](#jobsjob_idenv)을(를) 참조하세요. 둘 이상의 변수가 동일한 이름으로 정의되면 GitHub는 가장 구체적인 환경 변수를 사용합니다. 예를 들어 단계에 정의된 환경 변수는 단계가 실행되는 동안 동일한 이름의 작업 및 워크플로 환경 변수를 재정의합니다. 작업에 정의된 환경 변수는 작업이 실행되는 동안 동일한 이름의 워크플로 변수를 재정의합니다. 퍼블릭 작업은 README 파일에서 예상되는 변수를 지정할 수 있습니다. 암호 또는 토큰과 같은 비밀 또는 중요한 값을 설정하는 경우 `secrets` 컨텍스트를 사용하여 비밀을 설정해야 합니다. 자세한 내용은 [문맥 참조](/ko/actions/learn-github-actions/contexts)을(를) 참조하세요. ### ``` `jobs..steps[*].env`의 예 ``` ```yaml steps: - name: My first action env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} FIRST_NAME: Mona LAST_NAME: Octocat ``` ## `jobs..steps[*].continue-on-error` 단계가 실패해도 작업이 실패하지 않도록 방지합니다. 이 단계가 실패해도 작업이 통과되도록 `true`로 설정합니다. ## `jobs..steps[*].timeout-minutes` 프로세스를 종료하기 전에 단계를 실행할 최대 시간(분)입니다. 최대값: GitHub호스트 실행기와 자체 호스트 실행기 모두 360입니다. 소수 값은 지원되지 않습니다. `timeout-minutes`은(는) 양의 정수여야 합니다. ## `jobs..timeout-minutes` 실행된 작업을 GitHub에서 자동으로 취소하기 전까지 걸리는 최대 시간(분)입니다. 기본값: 360 시간 제한이 실행기의 작업 실행 시간 제한을 초과하는 경우 실행 시간 한도에 다다르면 작업이 취소됩니다. 작업 실행 시간 제한에 대한 자세한 내용은 GitHub 호스트 실행기에 대한 [청구 및 사용량](/ko/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits)과 자체 호스트 실행기 사용 제한에 대한 [작업 제한](/ko/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners)을 참조하세요. > \[!NOTE] ``` `GITHUB_TOKEN`은 작업이 완료되거나 최대 24시간 후에 만료됩니다. 자체 호스팅 실행기에서 작업 시간 제한이 24시간보다 큰 경우 토큰이 제한 요인이 될 수 있습니다. ``` ``` `GITHUB_TOKEN`에 대한 자세한 내용은 [AUTOTITLE](/actions/security-guides/automatic-token-authentication#about-the-github_token-secret)을(를) 참조하세요. ``` ## `jobs..strategy` ``` `jobs..strategy`를 사용하여 작업에 행렬 전략을 사용합니다. 매트릭스 전략을 사용하면 단일 작업 정의에서 변수를 사용하여 변수의 조합을 기반으로 하는 여러 작업 실행을 자동으로 만들 수 있습니다. 예를 들어 매트릭스 전략을 사용하여 여러 버전의 언어 또는 여러 운영 체제에서 코드를 테스트할 수 있습니다. 자세한 내용은 [AUTOTITLE](/actions/using-jobs/using-a-matrix-for-your-jobs)을 참조하세요. ``` ## `jobs..strategy.matrix` ``` `jobs..strategy.matrix`를 사용하여 다양한 작업 구성 행렬을 정의합니다. 자세한 내용은 [AUTOTITLE](/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow)을(를) 참조하세요. ``` 행렬은 워크플로 실행당 최대 256개의 작업을 생성합니다. 이 제한은 GitHub-호스트 실행기와 자체 호스트 실행기 모두에 적용됩니다. 정의하는 변수는 `matrix` 컨텍스트의 속성이 되며 워크플로 파일의 다른 영역에서 속성을 참조할 수 있습니다. 이 예제에서는 `matrix.version` 및 `matrix.os`를 사용하여 작업에서 사용 중인 `version` 및 `os`의 현재 값에 액세스할 수 있습니다. 자세한 내용은 [문맥 참조](/ko/actions/learn-github-actions/contexts)을(를) 참조하세요. 기본적으로 GitHub 실행기 가용성에 따라 병렬로 실행되는 작업 수를 최대화합니다. 행렬의 변수 순서에 따라 작업이 생성되는 순서가 결정됩니다. 정의한 첫 번째 변수는 워크플로 실행에서 만든 첫 번째 작업이 됩니다. ### 1차원 매트릭스 사용 예를 들어 다음 워크플로는 `version` 값을 사용하여 `[10, 12, 14]` 변수를 정의합니다. 워크플로는 변수의 각 값에 대해 하나씩 3개의 작업을 실행합니다. 각 작업은 `version` 컨텍스트를 통해 `matrix.version` 값에 액세스하고 해당 값을 `node-version` 작업에 `actions/setup-node`으로 전달합니다. ```yaml jobs: example_matrix: strategy: matrix: version: [10, 12, 14] steps: - uses: actions/setup-node@v4 with: node-version: ${{ matrix.version }} ``` ### 다차원 매트릭스 사용 여러 변수를 지정하여 다차원 매트릭스를 만듭니다. 가능한 각 변수 조합에 대해 작업이 실행됩니다. 예를 들어 다음 워크플로는 두 개의 변수를 지정합니다. * `os` 변수에 지정된 운영 체제 2개 * `version` 변수에 지정된 Node.js 버전 3개 워크플로는 `os` 및 `version` 변수의 각 조합에 대해 하나씩 6개의 작업을 실행합니다. 각 작업은 `runs-on` 값을 현재 `os` 값으로 설정하고 현재 `version` 값을 `actions/setup-node` 작업에 전달합니다. ```yaml jobs: example_matrix: strategy: matrix: os: [ubuntu-22.04, ubuntu-24.04] version: [10, 12, 14] runs-on: ${{ matrix.os }} steps: - uses: actions/setup-node@v4 with: node-version: ${{ matrix.version }} ``` 매트릭스의 변수 구성은 `array`의 `object`일 수 있습니다. 예를 들어 다음 매트릭스는 해당 컨텍스트를 사용하여 4개의 작업을 생성합니다. ```yaml matrix: os: - ubuntu-latest - macos-latest node: - version: 14 - version: 20 env: NODE_OPTIONS=--openssl-legacy-provider ``` 매트릭스의 각 작업에는 아래와 같이 `os` 및 `node` 값의 고유한 조합이 있습니다. ```yaml - matrix.os: ubuntu-latest matrix.node.version: 14 - matrix.os: ubuntu-latest matrix.node.version: 20 matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider - matrix.os: macos-latest matrix.node.version: 14 - matrix.os: macos-latest matrix.node.version: 20 matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider ``` ## `jobs..strategy.matrix.include` ``` `include` 목록의 각 개체에서 키:값 쌍이 원래 행렬 값을 덮어쓰지 않으면 개체의 키:값 쌍이 각 행렬 조합에 추가됩니다. 개체를 행렬 조합에 추가할 수 없는 경우 대신 새 행렬 조합이 만들어집니다. 원래 행렬 값은 덮어쓰는 것이 아니라 추가된 행렬 값을 덮어쓸 수 있습니다. ``` ### 예: 구성 확장 예를 들어, 다음 워크플로는 `os` 및 `node`의 각 조합에 대해 하나씩 4개의 작업을 실행합니다. `windows-latest`의 `os` 값과 `16`의 `node` 값에 대한 작업이 실행되면 `6` 값을 사용하는 `npm`이라는 추가 변수가 작업에 포함됩니다. ```yaml jobs: example_matrix: strategy: matrix: os: [windows-latest, ubuntu-latest] node: [14, 16] include: - os: windows-latest node: 16 npm: 6 runs-on: ${{ matrix.os }} steps: - uses: actions/setup-node@v4 with: node-version: ${{ matrix.node }} - if: ${{ matrix.npm }} run: npm install -g npm@${{ matrix.npm }} - run: npm --version ``` ### 예: 구성 추가 예를 들어 이 매트릭스는 매트릭스의 `os` 및 `version` 각 조합에 대해 하나씩 10개의 작업과 `windows-latest`의 `os` 값과 `17`의 `version` 값에 대한 작업을 실행합니다. ```yaml jobs: example_matrix: strategy: matrix: os: [macos-latest, windows-latest, ubuntu-latest] version: [12, 14, 16] include: - os: windows-latest version: 17 ``` 매트릭스 변수를 지정하지 않으면 `include` 아래의 모든 구성이 실행됩니다. 예를 들어 다음 워크플로는 각 `include` 항목에 대해 하나씩 두 개의 작업을 실행합니다. 이렇게 하면 완전히 채워진 매트릭스 없이 매트릭스 전략을 활용할 수 있습니다. ```yaml jobs: includes_only: runs-on: ubuntu-latest strategy: matrix: include: - site: "production" datacenter: "site-a" - site: "staging" datacenter: "site-b" ``` ## `jobs..strategy.matrix.exclude` 제외된 구성은 제외되려면 부분 일치여야 합니다. 모든 `include` 조합은 `exclude` 다음에 처리됩니다. `include`를 사용하여 이전에 제외된 조합을 다시 추가하는 데 사용할 수 있습니다. ## `jobs..strategy.fail-fast` `jobs..strategy.fail-fast` 및 `jobs..continue-on-error`로 작업 오류를 처리하는 방법을 제어할 수 있습니다. `jobs..strategy.fail-fast`는 전체 행렬에 적용됩니다. `jobs..strategy.fail-fast`가 `true`로 설정되거나 식이 `true`로 평가되면 GitHub는 행렬의 작업이 실패할 경우 행렬의 진행 중인 작업과 대기 중인 작업을 모두 취소합니다. 이 속성은 기본적으로 `true`입니다. `jobs..continue-on-error`는 단일 작업에 적용됩니다. `jobs..continue-on-error`가 `true`인 경우 `jobs..continue-on-error: true`인 작업이 실패하더라도 행렬의 다른 작업은 계속 실행됩니다. `jobs..strategy.fail-fast` 및 `jobs..continue-on-error`를 함께 사용할 수 있습니다. 예를 들어 다음 워크플로는 4개의 작업을 시작합니다. 각 작업에 대해 `continue-on-error`는 `matrix.experimental` 값으로 결정됩니다. `continue-on-error: false`인 작업이 실패하면 진행 중이거나 큐에 대기 중인 모든 작업이 취소됩니다. `continue-on-error: true`인 작업이 실패하면 다른 작업은 영향을 받지 않습니다. ```yaml jobs: test: runs-on: ubuntu-latest continue-on-error: ${{ matrix.experimental }} strategy: fail-fast: true matrix: version: [6, 7, 8] experimental: [false] include: - version: 9 experimental: true ``` ## `jobs..strategy.max-parallel` 기본적으로 GitHub 실행기 가용성에 따라 병렬로 실행되는 작업 수를 최대화합니다. ## `jobs..continue-on-error` ``` `jobs..continue-on-error`은(는) 단일 작업에 적용됩니다. `jobs..continue-on-error`가 `true`인 경우 `jobs..continue-on-error: true`인 작업이 실패하더라도 행렬의 다른 작업은 계속 실행됩니다. ``` 작업이 실패해도 워크플로 실행이 실패하지 않도록 방지합니다. 이 작업이 실패해도 워크플로 실행이 통과하도록 `true`로 설정합니다. ### 예제: 특정 실패 매트릭스 작업으로 인해 워크플로 실행에 실패하지 않도록 방지 워크플로 실행에 실패하지 않고 작업 행렬의 특정 작업이 실패하도록 허용할 수 있습니다. 예를 들어 워크플로 실행에 실패하지 않도록 `node`가 `15`로 설정된 실험 작업만 실패하도록 허용하려는 경우입니다. ```yaml runs-on: ${{ matrix.os }} continue-on-error: ${{ matrix.experimental }} strategy: fail-fast: false matrix: node: [13, 14] os: [macos-latest, ubuntu-latest] experimental: [false] include: - node: 15 os: ubuntu-latest experimental: true ``` ## `jobs..container` > \[!NOTE] > 워크플로에서 Docker 컨테이너 작업, 작업 컨테이너, 서비스 컨테이너를 사용하는 경우, Linux 실행기를 사용해야 합니다. > > * GitHub에서 호스트되는 실행기를 사용하는 경우 Ubuntu 실행기를 사용해야 합니다. > * 자체 호스팅 실행기를 사용하는 경우 실행기로 Linux 컴퓨터를 사용해야 하며 Docker를 설치해야 합니다. `jobs..container`를 사용하여 컨테이너를 아직 지정하지 않은 작업에서 모든 단계를 실행하는 컨테이너를 만듭니다. 스크립트 및 컨테이너 작업을 둘 다 사용하는 단계가 있는 경우 컨테이너 작업은 동일한 볼륨 탑재가 있는 동일한 네트워크에서 형제 컨테이너로 실행됩니다. `container`를 설정하지 않으면 단계가 컨테이너에서 실행되도록 구성된 작업을 참조하지 않는 한, 모든 단계가 `runs-on`으로 지정된 호스트에서 직접 실행됩니다. > \[!NOTE] > 컨테이너 내의 `run` 단계에 대한 기본 셸은 `bash`가 아니라 `sh`입니다. 이 셸은 [`jobs..defaults.run`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun) 또는 [`jobs..steps[*].shell`](/ko/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell)로 재정의할 수 있습니다. ### 예: 컨테이너 내에서 작업 실행 ```yaml copy name: CI on: push: branches: [ main ] jobs: container-test-job: runs-on: ubuntu-latest container: image: node:18 env: NODE_ENV: development ports: - 80 volumes: - my_docker_volume:/volume_mount options: --cpus 1 steps: - name: Check for dockerenv file run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv) ``` 컨테이너 이미지만 지정하면 `image` 키워드를 생략해도 됩니다. ```yaml jobs: container-test-job: runs-on: ubuntu-latest container: node:18 ``` ## `jobs..container.image` `jobs..container.image`를 사용하여 작업을 실행하기 위한 컨테이너로 사용할 Docker 이미지를 정의합니다. 값은 Docker Hub 이미지 이름 또는 레지스트리 이름일 수 있습니다. > \[!NOTE] > Docker Hub는 일반적으로 자체 호스팅 러너에서 작업에 영향을 미치는 밀어넣기 및 끌어오기 작업 모두에 속도 제한을 적용합니다. 그러나 GitHub 호스팅 러너는 GitHub 및 Docker 간의 규약에 따라 이러한 제한을 받지 않습니다. ## `jobs..container.credentials` 이미지의 컨테이너 레지스트리에서 이미지를 끌어오기 위해 인증이 필요한 경우 `jobs..container.credentials`를 사용하여 `username` 및 `password`의 `map`을 설정할 수 있습니다. 자격 증명은 [`docker login`](https://docs.docker.com/engine/reference/commandline/login/) 명령에 제공하는 것과 동일한 값입니다. ### 예: 컨테이너 레지스트리에 대한 자격 증명 정의 ```yaml container: image: ghcr.io/owner/image credentials: username: ${{ github.actor }} password: ${{ secrets.github_token }} ``` ## `jobs..container.env` `jobs..container.env`를 사용하여 컨테이너에서 환경 변수의 `map`을 설정합니다. ## `jobs..container.ports` `jobs..container.ports`를 사용하여 컨테이너에 노출할 포트의 `array`를 설정합니다. ## `jobs..container.volumes` `jobs..container.volumes`를 사용하여 서비스 컨테이너에서 사용할 볼륨의 `array`를 설정합니다. 볼륨을 사용하여 서비스 또는 작업의 여러 단계 간에 데이터를 공유할 수 있습니다. 명명된 Docker 볼륨, 익명 Docker 볼륨 또는 호스트의 바인딩 탑재를 지정할 수 있습니다. 볼륨을 지정하려면 원본 및 대상 경로를 지정합니다. `:`입니다. ``는 호스트 컴퓨터의 볼륨 이름 또는 절대 경로이며 ``는 컨테이너의 절대 경로입니다. ### 예제: 컨테이너에 볼륨 탑재 ```yaml volumes: - my_docker_volume:/volume_mount - /data/my_data - /source/directory:/destination/directory ``` ## `jobs..container.options` `jobs..container.options`를 사용하여 추가 Docker 컨테이너 리소스 옵션을 구성합니다. 옵션 목록은 [`docker create` 옵션](https://docs.docker.com/engine/reference/commandline/create/#options)을 참조하세요. > \[!WARNING] > `--network` 및 `--entrypoint` 옵션은 지원되지 않습니다. ## `jobs..services` > \[!NOTE] > 워크플로에서 Docker 컨테이너 작업, 작업 컨테이너, 서비스 컨테이너를 사용하는 경우, Linux 실행기를 사용해야 합니다. > > * GitHub에서 호스트되는 실행기를 사용하는 경우 Ubuntu 실행기를 사용해야 합니다. > * 자체 호스팅 실행기를 사용하는 경우 실행기로 Linux 컴퓨터를 사용해야 하며 Docker를 설치해야 합니다. 워크플로에서 작업에 대한 서비스 컨테이너를 호스트하는 데 사용됩니다. 서비스 컨테이너는 데이터베이스 또는 Redis와 같은 캐시 서비스를 만드는 데 유용합니다. 실행기는 Docker 네트워크를 자동으로 만들고 서비스 컨테이너의 수명 주기를 관리합니다. 컨테이너에서 실행되도록 작업을 구성하거나 단계에서 컨테이너 작업을 사용하는 경우 포트를 매핑하여 서비스 또는 작업에 액세스할 필요가 없습니다. Docker는 동일한 Docker 사용자 정의 브리지 네트워크의 컨테이너 간 모든 포트를 자동으로 노출합니다. 호스트 이름으로 서비스 컨테이너를 직접 참조할 수 있습니다. 호스트 이름은 워크플로에서 서비스에 대해 구성하는 레이블 이름에 자동으로 매핑됩니다. 실행기 컴퓨터에서 직접 실행되도록 작업을 구성하고 단계에서 컨테이너 작업을 사용하지 않는 경우 필요한 Docker 서비스 컨테이너 포트를 Docker 호스트(실행기 머신)에 매핑해야 합니다. localhost 및 매핑된 포트를 사용하여 서비스 컨테이너에 액세스할 수 있습니다. ``` [AUTOTITLE](/actions/using-containerized-services/about-service-containers)에서 네트워킹 서비스 컨테이너 간의 차이점에 대한 자세한 내용을 참조하세요. ``` ### 예제: localhost 사용 이 예제에서는 nginx 및 redis라는 두 가지 서비스를 만듭니다. 호스트 포트가 아닌 컨테이너 포트를 지정하는 경우, 호스트의 사용 가능한 포트에 컨테이너 포트가 임의로 할당됩니다. GitHub 는 컨텍스트에서 할당된 호스트 포트를 `${{job.services..ports}}` 설정합니다. 이 예제에서는 및`${{ job.services.nginx.ports['80'] }}`컨텍스트를 사용하여 서비스 호스트 포트에 `${{ job.services.redis.ports['6379'] }}` 액세스할 수 있습니다. ```yaml services: nginx: image: nginx # Map port 8080 on the Docker host to port 80 on the nginx container ports: - 8080:80 redis: image: redis # Map random free TCP port on Docker host to port 6379 on redis container ports: - 6379/tcp steps: - run: | echo "Redis available on 127.0.0.1:${{ job.services.redis.ports['6379'] }}" echo "Nginx available on 127.0.0.1:${{ job.services.nginx.ports['80'] }}" ``` ## `jobs..services..image` 작업을 실행하기 위해 서비스 컨테이너로 사용할 Docker 이미지입니다. 값은 Docker Hub 이미지 이름 또는 레지스트리 이름일 수 있습니다. ``` `jobs..services..image`에 빈 문자열이 할당되면 서비스가 시작되지 않습니다. 이를 사용해 다음 예시와 유사한 조건부 서비스를 설정할 수 있습니다. ``` ```yaml services: nginx: image: ${{ options.nginx == true && 'nginx' || '' }} ``` ## `jobs..services..credentials` 이미지의 컨테이너 레지스트리에서 이미지를 끌어오기 위해 인증이 필요한 경우 `jobs..container.credentials`를 사용하여 `username` 및 `password`의 `map`을 설정할 수 있습니다. 자격 증명은 [`docker login`](https://docs.docker.com/engine/reference/commandline/login/) 명령에 제공하는 것과 동일한 값입니다. ### ``` `jobs..services..credentials`의 예 ``` ```yaml services: myservice1: image: ghcr.io/owner/myservice1 credentials: username: ${{ github.actor }} password: ${{ secrets.github_token }} myservice2: image: dockerhub_org/myservice2 credentials: username: ${{ secrets.DOCKER_USER }} password: ${{ secrets.DOCKER_PASSWORD }} ``` ## `jobs..services..env` 서비스 컨테이너의 `map` 환경 변수를 설정합니다. ## `jobs..services..ports` 서비스 컨테이너에 노출할 포트의 `array`를 설정합니다. ## `jobs..services..volumes` 사용할 서비스 컨테이너에 대한 볼륨의 `array`를 설정합니다. 볼륨을 사용하여 서비스 또는 작업의 여러 단계 간에 데이터를 공유할 수 있습니다. 명명된 Docker 볼륨, 익명 Docker 볼륨 또는 호스트의 바인딩 탑재를 지정할 수 있습니다. 볼륨을 지정하려면 원본 및 대상 경로를 지정합니다. ``` `:`; ``는 호스트 컴퓨터의 볼륨 이름 또는 절대 경로이며 ``는 컨테이너의 절대 경로입니다. ``` ### ``` `jobs..services..volumes`의 예 ``` ```yaml volumes: - my_docker_volume:/volume_mount - /data/my_data - /source/directory:/destination/directory ``` ## `jobs..services..options` 추가 Docker 컨테이너 리소스 옵션입니다. 옵션 목록은 [`docker create` 옵션](https://docs.docker.com/engine/reference/commandline/create/#options)을 참조하세요. > \[!WARNING] ``` `--network` 옵션은 지원되지 않습니다. ``` ## `jobs..services..command` Docker 이미지의 기본 명령(`CMD`)을 재정의합니다. 이 값은 명령에서 이미지 이름 `docker create` 뒤의 인수로 전달됩니다. `entrypoint`와 함께 `command`을(를) 지정하면 해당 진입점에 대한 인수를 제공합니다. ### ``` `jobs..services..command`의 예 ``` ```yaml services: mysql: image: mysql:8 command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M env: MYSQL_ROOT_PASSWORD: test ports: - 3306:3306 ``` ## `jobs..services..entrypoint` Docker 이미지의 기본값 `ENTRYPOINT`을 재정의합니다. 값은 실행할 실행 파일을 정의하는 단일 문자열입니다. 이미지의 진입점을 완전히 바꿔야 할 때 사용합니다. 사용자 지정 진입점에 인수를 전달하기 위해 결합 `entrypoint``command` 할 수 있습니다. ### ``` `jobs..services..entrypoint`의 예 ``` ```yaml services: etcd: image: quay.io/coreos/etcd:v3.5.17 entrypoint: etcd command: >- --listen-client-urls http://0.0.0.0:2379 --advertise-client-urls http://0.0.0.0:2379 ports: - 2379:2379 ``` ## `jobs..uses` 작업으로 실행할 재사용 가능한 워크플로 파일의 위치 및 버전입니다. 다음 구문 중 하나를 사용하십시오. * 퍼블릭 및 프라이빗 리포지토리에서 재사용 가능한 워크플로의 경우 `{owner}/{repo}/.github/workflows/{filename}@{ref}`입니다. * 동일한 리포지토리에서 다시 사용할 수 있는 워크플로의 경우 `./.github/workflows/{filename}`입니다. 첫 번째 선택에서 `{ref}`은(는) SHA, 릴리스 태그 또는 분기 이름을 사용할 수 있습니다. 릴리스 태그와 분기의 이름이 같으면 릴리스 태그가 분기 이름보다 우선합니다. 안정성과 보안을 위해서는 커밋 SHA를 사용하는 것이 가장 안전합니다. 자세한 내용은 [안전 사용 참조](/ko/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)을(를) 참조하세요. 두 번째 구문 옵션(`{owner}/{repo}`, `@{ref}` 없음)을 사용하는 경우 호출된 워크플로는 호출자 워크플로와 동일한 커밋에서 가져옵니다. `refs/heads`, `refs/tags` 등의 참조 접두사는 사용할 수 없습니다. 이 키워드에는 컨텍스트 또는 식을 사용할 수 없습니다. ### ``` `jobs..uses`의 예 ``` ```yaml jobs: call-workflow-1-in-local-repo: uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89 call-workflow-2-in-local-repo: uses: ./.github/workflows/workflow-2.yml call-workflow-in-another-repo: uses: octo-org/another-repo/.github/workflows/workflow.yml@v1 ``` 자세한 내용은 [워크플로 재사용](/ko/actions/using-workflows/reusing-workflows)을(를) 참조하세요. ## `jobs..with` 작업을 사용하여 재사용 가능한 워크플로를 호출하는 경우 `with`사용하여 워크플로에 전달되는 입력 맵을 제공할 수 있습니다. 전달하는 모든 입력은 호출된 워크플로에 정의된 입력 사양과 일치해야 합니다. ``` [ `jobs..steps[*].with` ](#jobsjob_idstepswith)와는 달리, `jobs..with`을(를) 통해 전달하는 입력은 호출된 워크플로에서 환경 변수로 사용할 수 없습니다. 대신 `inputs` 컨텍스트를 사용하여 입력을 참조할 수 있습니다. ``` ### ``` `jobs..with`의 예 ``` ```yaml jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main with: username: mona ``` ## `jobs..with.` 입력 및 입력 값에 대한 문자열 식별자로 구성된 쌍입니다. 호출된 워크플로의 [`on.workflow_call.inputs.`](/ko/actions/creating-actions/metadata-syntax-for-github-actions#inputsinput_id)에 정의된 입력의 이름과 식별자가 일치해야 합니다. 호출된 워크플로의 [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype)에 정의된 형식과 값의 데이터 형식이 일치해야 합니다. 허용되는 언어 식 컨텍스트: `github`및 `needs` ## `jobs..secrets` 작업을 사용하여 재사용 가능한 워크플로를 호출하는 경우 `secrets`를 사용하여 호출된 워크플로에 전달되는 비밀 맵을 제공할 수 있습니다. 전달하는 모든 비밀은 호출된 워크플로에 정의된 이름과 일치해야 합니다. ### ``` `jobs..secrets`의 예 ``` ```yaml jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main secrets: access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} ``` ## `jobs..secrets.inherit` ``` `inherit` 키워드를 사용하여 호출 워크플로의 모든 비밀을 호출된 워크플로에 전달합니다. 여기에는 호출 워크플로가 액세스할 수 있는 모든 비밀, 즉 조직, 리포지토리, 환경 비밀이 포함됩니다. `inherit` 키워드는 동일한 조직 내의 리포지토리 또는 동일한 엔터프라이즈 내의 조직 간에 비밀을 전달하는 데 사용할 수 있습니다. ``` ### ``` `jobs..secrets.inherit`의 예 ``` ```yaml on: workflow_dispatch: jobs: pass-secrets-to-workflow: uses: ./.github/workflows/called-workflow.yml secrets: inherit ``` ```yaml on: workflow_call: jobs: pass-secret-to-action: runs-on: ubuntu-latest steps: - name: Use a repo or org secret from the calling workflow. run: echo ${{ secrets.CALLING_WORKFLOW_SECRET }} ``` ## `jobs..secrets.` 비밀의 문자열 식별자와 비밀 값으로 구성된 쌍입니다. 호출된 워크플로의 [`on.workflow_call.secrets.`](#onworkflow_callsecretssecret_id)에 정의된 비밀의 이름과 식별자가 일치해야 합니다. 허용되는 언어 식 컨텍스트: `github`, `needs`, `secrets` ## 필터 패턴 치트 시트 경로, 분기, 태그 필터에서 특수 문자를 사용할 수 있습니다. * `*`: 0개 이상의 문자와 일치하지만 `/` 문자와 일치하지 않습니다. 예를 들어 `Octo*`은 `Octocat`와 일치합니다. * `**`: 0개 이상의 문자와 일치합니다. * `?`: 0개 또는 1개의 앞 문자와 일치합니다. * `+`: 0개 이상의 앞 문자와 일치합니다. * `[]`: 대괄호로 묶거나 범위에 포함된 1개의 영숫자와 일치합니다. 범위에는 `a-z`, `A-Z`, `0-9`만이 포함될 수 있습니다. 예를 들어 `[0-9a-z]` 범위가 모든 숫자 또는 소문자와 일치하는 경우가 있습니다. 예를 들어 `[CB]at` 일치 `Cat` 또는 `Bat` 및 `[1-2]00`이 `100` 및`200`과 일치하는 경우가 있습니다. * `!`: 패턴이 시작되면 이전의 양수 패턴이 무효화됩니다. 첫 번째 문자가 아니라면 특별한 의미가 없습니다. ``` `*`, `[`, `!`는 YAML의 특수 문자입니다. 패턴을 `*`, `[`, `!`로 시작하는 경우 패턴을 따옴표로 묶어야 합니다. 또한 [](https://yaml.org/spec/1.2.2/#flow-sequences) 및/또는 `[`가 포함된 패턴이 있는 `]`를 사용하는 경우 패턴은 따옴표로 묶어야 합니다. ``` ```yaml # Valid paths: - '**/README.md' # Invalid - creates a parse error that # prevents your workflow from running. paths: - **/README.md # Valid branches: [ main, 'release/v[0-9].[0-9]' ] # Invalid - creates a parse error branches: [ main, release/v[0-9].[0-9] ] ``` 분기, 태그, 경로 필터 구문에 대한 자세한 내용은 [`on..`](#onpushbranchestagsbranches-ignoretags-ignore), [`on..`](#onpull_requestpull_request_targetbranchesbranches-ignore), 및 [`on..paths`](#onpushpull_requestpull_request_targetpathspaths-ignore)을(를) 참조하세요. ### 분기 및 태그와 일치하는 패턴 | 패턴 | 설명 | 일치하는 예제 | | ----------- | -- | ------- | | `feature/*` | | | ``` `*` 와일드카드는 문자와 일치하지만 슬래시(`/`)와는 일치하지 않습니다. | `feature/my-branch`

`feature/your-branch` | ``` \| `feature/**` | `**` 와일드카드는 분기 및 태그 이름의 슬래시(`/`)를 비롯한 모든 문자와 일치합니다. | `feature/beta-a/my-branch`

`feature/your-branch`

`feature/mona/the/octocat` | \| `main`

`releases/mona-the-octocat` | 분기 또는 태그 이름의 정확한 이름과 일치합니다. | `main`

`releases/mona-the-octocat` | \| `'*'` | 슬래시(`/`)를 포함하지 않는 모든 분기 및 태그 이름과 일치합니다. `*` 문자는 YAML의 특수 문자입니다. 패턴을 `*`시작할 때 따옴표를 사용해야 합니다. | `main`

`releases` | \| `'**'` | 모든 분기 및 태그 이름과 일치합니다. 이는 `branches` 또는 `tags` 필터를 사용하지 않는 경우 기본 동작입니다. | `all/the/branches`

`every/tag` | \| `'*feature'` | `*` 문자는 YAML의 특수 문자입니다. 패턴을 `*`시작할 때 따옴표를 사용해야 합니다. | `mona-feature`

`feature`

`ver-10-feature` | \| `v2*` | `v2`로 시작하는 분기 및 태그 이름과 일치합니다. | `v2`

`v2.0`

`v2.9` | \| `v[12].[0-9]+.[0-9]+` | 모든 주 버전이 1 또는 2인 의미 체계 버전 관리 분기 및 태그와 일치합니다. | `v1.10.1`

`v2.0.0` | ### 파일 경로와 일치하는 패턴 경로 패턴은 전체 경로와 일치해야 하며 리포지토리의 루트에서 시작해야 합니다. | 패턴 | 일치 항목에 대한 설명 | 일치하는 예제 | | ----- | ------------ | ------- | | `'*'` | | | ``` `*` 와일드카드는 문자와 일치하지만 슬래시(`/`)와는 일치하지 않습니다. `*` 문자는 YAML의 특수 문자입니다. 패턴을 `*`시작할 때 따옴표를 사용해야 합니다. | `README.md`

`server.rb` | ``` \| `'*.jsx?'` | `?` 문자는 0개 또는 1개의 앞의 문자와 일치합니다. | `page.js`

`page.jsx` | \| `'**'` | `**` 와일드카드는 슬래시(`/`)를 포함한 모든 문자와 일치합니다. 이는 `path` 필터를 사용하지 않는 경우 기본 동작입니다. | `all/the/files.md` | \| `'*.js'` | `*` 와일드카드는 문자와 일치하지만 슬래시(`/`)와는 일치하지 않습니다. 리포지토리의 루트에 있는 모든 `.js` 파일을 일치합니다. | `app.js`

`index.js` | \| `'**.js'` | 리포지토리의 모든 `.js` 파일에 일치합니다. | `index.js`

`js/index.js`

`src/js/app.js` | \| `docs/*` | 리포지토리 루트의 `docs` 디렉터리 루트 내에만 있는 모든 파일. | `docs/README.md`

`docs/file.txt` | \| `docs/**` | `docs` 디렉터리와 리포지토리 루트의 하위 디렉터리에 있는 모든 파일. | `docs/README.md`

`docs/mona/octocat.txt` | \| `docs/**/*.md` | `.md` 디렉터리 내 모든 위치의 `docs` 접미사가 있는 파일입니다. | `docs/README.md`

`docs/mona/hello-world.md`

`docs/a/markdown/file.md` | \| `'**/docs/**'` | 리포지토리 내 모든 위치의 `docs` 디렉터리의 모든 파일입니다. | `docs/hello.md`

`dir/docs/my-file.txt`

`space/docs/plan/space.doc` | \| `'**/README.md'` | 리포지토리 내 모든 위치의 README.md 파일입니다. | `README.md`

`js/README.md` | \| `'**/*src/**'` | 리포지토리 내 모든 위치의 접미사가 `src`인 폴더의 모든 파일입니다. | `a/src/app.js`

`my-src/code/js/app.js` | \| `'**/*-post.md'` | 리포지토리 내 모든 위치의 접미사가 `-post.md`인 파일입니다. | `my-post.md`

`path/their-post.md` | \| `'**/migrate-*.sql'` | 리포지토리 내 모든 위치의 접두사가 `migrate-`이고 접미사가 `.sql`인 파일입니다. | `migrate-10909.sql`

`db/migrate-v1.0.sql`

`db/sept/migrate-v1.sql` | \| `'*.md'`

`'!README.md'` | 패턴 앞에 느낌표(`!`)를 사용하면 무효화됩니다. 파일이 패턴과 일치하고 파일의 뒷부분에서 정의된 음수 패턴과 일치하면 파일이 포함되지 않습니다. | `hello.md`

*일치하지 않는 항목*

`README.md`

`docs/hello.md` | \| `'*.md'`

`'!README.md'`

`README*` | 패턴은 순차적으로 검사됩니다. 이전 패턴을 무효화하는 패턴은 파일 경로를 다시 포함합니다. | `hello.md`

`README.md`

`README.doc` |