이 버전의 GitHub Enterprise Server는 다음 날짜에 중단됩니다. 2026-04-09. 중요한 보안 문제에 대해서도 패치 릴리스가 이루어지지 않습니다. 더 뛰어난 성능, 향상된 보안, 새로운 기능을 위해 최신 버전의 GitHub Enterprise Server로 업그레이드합니다. 업그레이드에 대한 도움말은 GitHub Enterprise 지원에 문의하세요.

GitHub Actions에 대한 워크플로 구문

워크플로는 하나 이상의 작업으로 구성된 구성 가능한 자동화된 프로세스입니다. 워크플로 구성을 정의하려면 YAML 파일을 만들어야 합니다.

이 기사에서

참고

GitHub 호스트 실행기는 현재 GitHub Enterprise Server에서 지원되지 않습니다.

워크플로에 대한 YAML 구문 정보

워크플로 파일은 YAML 구문을 사용하며 파일 확장명이 .yml 또는 .yaml이어야 합니다. YAML을 처음 사용하며 자세히 알아보려는 경우 Y분 안에 YAML 알아보기를 참조하세요.

워크플로 파일을 리포지토리의 .github/workflows 디렉터리에 저장해야 합니다.

`name`

워크플로의 이름입니다. GitHub은(는) 리포지토리의 "작업" 탭 아래에 워크플로의 이름을 표시합니다. name을 생략하면 GitHub은(는) 리포지토리의 루트를 기준으로 워크플로 파일 경로를 표시합니다.

`run-name`

워크플로 실행의 이름은 워크플로에서 생성됩니다. GitHub 는 리포지토리의 "작업" 탭에 있는 워크플로 실행 목록에 워크플로 실행 이름을 표시합니다. 생략되거나 공백만 있는 경우 run-name 실행 이름은 워크플로 실행에 대한 이벤트별 정보로 설정됩니다. 예를 들어 이벤트 또는 push 이벤트에 의해 pull_request 트리거되는 워크플로의 경우 커밋 메시지 또는 pull request 의 제목이 설정됩니다.

이 값은 식을 포함할 수 있으며 github 컨텍스트와 inputs 컨텍스트를 참조할 수 있습니다.

          `run-name`의 예

run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}

`on`

워크플로를 자동으로 트리거하려면 on을 사용하여 워크플로를 실행할 수 있는 이벤트를 정의합니다. 사용 가능한 이벤트 목록은 워크플로를 트리거하는 이벤트을(를) 참조하세요.

워크플로를 트리거하거나 시간 일정을 설정할 수 있는 단일 또는 여러 이벤트를 정의할 수 있습니다. 특정 파일, 태그 또는 분기 변경에 대해서만 워크플로 실행이 이루어지도록 제한할 수도 있습니다. 다음 섹션에서는 이러한 방법에 대해 설명합니다.

단일 이벤트 사용

예를 들어 다음 on 값이 있는 워크플로는 워크플로 리포지토리의 분기로 푸시될 때 실행됩니다.

on: push

여러 이벤트 사용

단일 이벤트 또는 여러 이벤트를 지정할 수 있습니다. 예를 들어 다음 on 값이 있는 워크플로는 워크플로 리포지토리의 분기로 푸시될 때 실행됩니다.

on: [push, fork]

여러 이벤트를 지정하는 경우 워크플로를 트리거하려면 이러한 이벤트 중 하나만 발생해야 합니다. 워크플로에 대한 트리거 이벤트가 여러 개 동시에 발생하는 경우 워크플로 실행 여러 개가 트리거됩니다.

활동 유형 사용

일부 이벤트에는 워크플로가 실행되어야 하는 시기를 보다 정확하게 제어할 수 있는 활동 유형이 있습니다. on.<event_name>.types를 사용하여 워크플로 실행을 트리거할 이벤트 활동 유형을 정의합니다.

예를 들어 issue_comment 이벤트에는 created, edited 및 deleted 활동 유형이 있습니다. label 이벤트에 대해 워크플로가 트리거되면 레이블을 만들거나 편집하거나 삭제할 때마다 이 워크플로가 실행됩니다. label 이벤트에 대해 created 활동 유형을 지정하면 레이블을 편집하거나 삭제할 때가 아니라 레이블을 만들 때 워크플로가 실행됩니다.

on:
  label:
    types:
      - created

활동 유형을 여러 개 지정한 경우 워크플로를 트리거하려면 이러한 이벤트 활동 유형 중 하나만 발생해야 합니다. 워크플로에 대한 트리거 이벤트 활동 유형 여러 개가 동시에 발생하는 경우 워크플로 실행 여러 개가 트리거됩니다. 예를 들어 다음 워크플로는 이슈가 시작되거나 레이블이 지정될 때 트리거됩니다. 레이블 두 개가 지정된 이슈가 시작되면 워크플로 실행 세 개가 시작됩니다. 하나는 이슈 시작됨 이벤트를 위한 실행이고, 두 개는 이슈에 레이블이 지정됨 이벤트 두 개를 위한 실행입니다.

on:
  issues:
    types:
      - opened
      - labeled

각 이벤트 및 해당 활동 유형에 대한 자세한 내용은 워크플로를 트리거하는 이벤트을(를) 참조하세요.

필터 사용

일부 이벤트에는 워크플로가 실행되어야 하는 시기를 더 자세히 제어할 수 있는 필터가 있습니다.

예를 들어 push 이벤트에는 푸시가 발생하는 경우 대신 branches 필터와 일치하는 분기로 푸시가 발생하는 경우에만 워크플로가 실행되도록 하는 branches 필터가 있습니다.

on:
  push:
    branches:
      - main
      - 'releases/**'

여러 이벤트와 함께 활동 유형 및 필터 사용

이벤트에 대해 작업 유형 또는 필터를 지정하고 여러 이벤트에서 워크플로가 트리거되는 경우 각 이벤트를 별도로 구성해야 합니다. 구성이 없는 이벤트를 포함하여 모든 이벤트에 콜론(:)을 추가해야 합니다.

예를 들어 다음 on 값이 있는 워크플로는 다음과 같은 경우에 실행됩니다.

레이블이 생성되는 경우
리포지토리의 main 분기에 푸시되는 경우
GitHub Pages 사용 분기에 푸시되는 경우

on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

`on.<event_name>.types`

워크플로 실행을 트리거할 활동 유형을 정의하는 데 on.<event_name>.types을 사용합니다. 대부분의 GitHub 이벤트는 둘 이상의 활동 유형에 의해 트리거됩니다. 예를 들어 레이블이 created, edited 또는 deleted일 때 label이 트리거됩니다. types 키워드를 사용하면 워크플로를 실행하게 하는 작업의 범위를 좁힐 수 있습니다. 하나의 활동 유형만 웹후크 이벤트를 트리거하는 경우 types 키워드는 필요하지 않습니다.

이벤트 types 배열을 사용할 수 있습니다. 각 이벤트 및 해당 활동 유형에 대한 자세한 내용은 워크플로를 트리거하는 이벤트을(를) 참조하세요.

on:
  label:
    types: [created, edited]

`on.<pull_request|pull_request_target>.<branches|branches-ignore>`

pull_request 및 pull_request_target 이벤트를 사용하는 경우 특정 분기를 대상으로 하는 끌어오기 요청에 대해서만 실행되도록 워크플로를 구성할 수 있습니다.

분기 이름 패턴을 포함하려는 경우 또는 분기 이름 패턴을 포함하거나 제외하려는 경우 branches 필터를 사용합니다. 분기 이름 패턴만 제외하려는 경우 branches-ignore 필터를 사용합니다. 워크플로의 동일한 이벤트에 대해 branches 필터와 branches-ignore 필터 둘 다는 사용할 수 없습니다.

branches/branches-ignore 및 paths/paths-ignore를 둘 다 정의하는 경우 워크플로는 두 필터가 모두 충족될 때만 실행됩니다.

branches 및 branches-ignore 키워드는 *, **, +, ?, ! 및 두 개 이상의 분기 이름을 찾기 위한 기타 문자 등의 문자를 사용하는 GLOB 패턴을 허용합니다. 이름에 해당 문자가 포함되어 있고 리터럴 일치를 원하는 경우 각 특수 문자를 \로 이스케이프해야 합니다. glob 패턴에 대한 자세한 내용은 GitHub Actions에 대한 워크플로 구문을(를) 참조하세요.

예: 분기 포함

branches에 정의된 패턴은 Git ref의 이름에 따라 평가됩니다. 예를 들어 끌어오기 요청 대상 지정을 위한 pull_request 이벤트가 있을 때마다 다음 워크플로가 실행됩니다.

main으로 명명된 분기(refs/heads/main)
mona/octocat으로 명명된 분기(refs/heads/mona/octocat)
releases/10과 같이 이름이 releases/로 시작하는 분기(refs/heads/releases/10)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'

병합하기 전에 워크플로를 통과해야 하는 경우 경로 또는 분기 필터링을 사용하여 워크플로 실행을 건너뛰지 않아야 합니다. 자세한 내용은 워크플로 실행 건너뛰기 및 규칙 세트에 사용 가능한 규칙을(를) 참조하세요.

분기 필터링, 경로 필터링 또는 커밋 메시지로 인해 워크플로를 건너뛰는 경우 해당 워크플로와 연결된 검사는 “보류 중” 상태로 유지됩니다. 이러한 검사가 성공해야 하는 끌어오기 요청은 병합에서 차단됩니다.

예: 분기 제외

패턴이 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`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->

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를 대상으로 하는 끌어오기 요청에 대해서는 그러지 않습니다.

on:
  pull_request:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

`on.push.<branches|tags|branches-ignore|tags-ignore>`

push 이벤트를 사용하는 경우 특정 분기 또는 태그에서 실행되도록 워크플로를 구성할 수 있습니다.

태그 이름 패턴을 포함하려는 경우 또는 태그 이름 패턴을 포함하거나 제외하려는 경우 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를 둘 다 정의하는 경우 워크플로는 두 필터가 모두 충족될 때만 실행됩니다.

branches, branches-ignore, tags 및 tags-ignore 키워드는 두 개 이상의 분기 또는 태그 이름과 일치하도록 *, **, +, ?, ! 등의 문자를 사용하는 GLOB 패턴을 허용합니다. 이름에 해당 문자가 포함되어 있고 리터럴 일치를 원하는 경우 각 특수 문자를 \로 _이스케이프_해야 합니다. glob 패턴에 대한 자세한 내용은 GitHub Actions에 대한 워크플로 구문을(를) 참조하세요.

예: 분기 및 태그 포함

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)

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`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->

```
        `v2` 태그(`refs/tags/v2`)
```

        `v1.`처럼 이름이 `v1.9`으로 시작하는 태그(`refs/tags/v1.9`)

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에서는 실행되지 않습니다.

on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

`on.<push|pull_request|pull_request_target>.<paths|paths-ignore>`

push 및 pull_request 이벤트를 사용하는 경우 변경된 파일 경로에 따라 실행되도록 워크플로를 구성할 수 있습니다. 경로 필터는 태그 푸시에 대해 평가되지 않습니다.

파일 경로 패턴을 포함하려는 경우 또는 파일 경로 패턴을 포함 및 제외하려는 경우 paths 필터를 사용합니다. 파일 경로 패턴만 제외하려는 경우 paths-ignore 필터를 사용합니다. 워크플로의 동일한 이벤트에 대해 paths 필터와 paths-ignore 필터 둘 다는 사용할 수 없습니다. 단일 이벤트에 대한 경로 패턴을 포함 및 제외하려면 접두어 ! 문자와 함께 paths 필터를 사용하여 제외해야 하는 경로를 나타냅니다.

참고

paths 패턴을 정의하는 순서가 중요합니다.

긍정 일치 후 일치하는 부정 패턴(접두사 !)은 경로를 제외합니다.
부정 일치 후 일치하는 긍정 패턴은 경로를 다시 포함합니다.

branches/branches-ignore 및 paths/paths-ignore를 둘 다 정의하는 경우 워크플로는 두 필터가 모두 충족될 때만 실행됩니다.

paths 및 paths-ignore 키워드는 둘 이상의 경로 이름에 대한 일치 판정을 위해 * 및 ** 와일드카드 문자를 사용하는 GLOB 패턴을 허용합니다. 자세한 내용은 GitHub Actions에 대한 워크플로 구문을(를) 참조하세요.

예: 경로 포함

하나 이상의 경로가 paths 필터의 패턴과 일치하면 워크플로가 실행됩니다. 예를 들어 JavaScript 파일(.js)을 푸시할 때마다 다음 워크플로가 실행됩니다.

on:
  push:
    paths:
      - '**.js'

경로 필터링, 분기 필터링 또는 커밋 메시지로 인해 워크플로를 건너뛰는 경우 해당 워크플로와 연결된 검사는 “보류 중” 상태로 유지됩니다. 이러한 검사가 성공해야 하는 끌어오기 요청은 병합에서 차단됩니다.

예: 경로 제외

모든 경로 이름이 paths-ignore의 패턴과 일치하면 워크플로가 실행되지 않습니다. 경로 이름이 paths-ignore의 패턴과 일치하지 않는 경우 일부 경로 이름이 패턴과 일치하더라도 워크플로가 실행됩니다.

다음 경로 필터가 있는 워크플로는 리포지토리의 루트에 있는 docs 디렉터리 외부에 하나 이상의 파일이 포함된 push 이벤트에서만 실행됩니다.

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만 변경하는 푸시는 그러지 않습니다.

on:
  push:
    paths:
      - 'sub-project/**'
      - '!sub-project/docs/**'

Git 차이 비교

참고

1,000개를 초과하는 커밋을 푸시하거나 GitHub가 시간 제한으로 인해 차이를 생성하지 않는 경우 워크플로가 항상 실행됩니다.

필터는 변경된 파일을 평가하고 paths-ignore 또는 paths 목록에 따라 이를 실행하여 워크플로 실행 여부를 결정합니다. 변경된 파일이 없으면 워크플로가 실행되지 않습니다.

GitHub는 푸시에는 2개의 점 차이를, 끌어오기 요청에는 3개의 점 차이를 사용하여 변경된 파일 목록을 생성합니다.

끌어오기 요청: 세 개의 점 차이는 토픽 분기의 최신 버전과 토픽 분기가 기본 분기와 마지막으로 동기화된 커밋을 비교한 것입니다.
기존 분기로 푸시: 두 개의 점 차이는 헤드와 기본 SHA를 서로 직접 비교합니다.
새 분기로 푸시: 푸시된 가장 깊은 커밋의 상위 부모에 대한 두 개의 점 차이입니다.

참고

차이는 300개의 파일로 제한됩니다. 필터에서 반환된 처음 300개 파일에서 일치하지 않는 파일이 변경된 경우 워크플로가 실행되지 않습니다. 워크플로가 자동으로 실행되도록 보다 구체적인 필터를 만들어야 할 수 있습니다.

자세한 내용은 풀 리퀘스트에서 브랜치 비교하기을(를) 참조하세요.

`on.schedule`

          `on.schedule`을 사용하여 워크플로에 대한 시간 일정을 정의할 수 있습니다.

POSIX cron 구문을 사용하여 특정 시간에 실행되도록 워크플로를 예약합니다. 기본적으로 예약된 워크플로는 UTC로 실행됩니다. 필요에 따라 표준 시간대 인식 일정에 IANA 표준 시간대 문자열 을 사용하여 표준 시간대를 지정할 수 있습니다. 예약된 워크플로는 기본 분기의 최신 커밋에서 실행됩니다. 예약된 워크플로를 실행할 수 있는 가장 짧은 간격은 5분마다 한 번입니다.

참고

DST(일광 절약 시간제)를 관찰하는 표준 시간대로 설정된 timezone 일정의 경우 DST 스프링 포워드 전환 중에 건너뛴 시간에 예약된 워크플로가 다음 유효한 시간으로 진행됩니다. 예를 들어 오전 2시 30분 일정은 오전 3:00까지 진행됩니다.

Cron 구문에는 공백으로 구분된 5개의 필드가 있으며 각 필드는 시간 단위를 나타냅니다.

┌───────────── 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분에 실행되도록 워크플로를 트리거합니다.

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 단계를 건너뜁니다.

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.<input_id>.type을(를) 참조하세요.

          `default` 매개 변수가 설정되지 않은 경우 입력의 기본값은 부울의 경우 `false`, 숫자의 경우 `0`, 문자열의 경우 `""`입니다.

호출된 워크플로 내에서 inputs 컨텍스트를 사용하여 입력을 참조할 수 있습니다. 자세한 내용은 문맥 참조을(를) 참조하세요.

호출자 워크플로가 호출된 워크플로에 지정되지 않은 입력을 전달하면 오류가 발생합니다.

          `on.workflow_call.inputs`의 예

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 }}

자세한 내용은 워크플로 재사용을(를) 참조하세요.

`on.workflow_call.inputs.<input_id>.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`의 예

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.<job_id>.outputs을(를) 참조하세요. 자세한 내용은 워크플로 재사용을(를) 참조하세요.

`on.workflow_call.secrets`

호출된 워크플로에서 사용할 수 있는 비밀의 맵입니다.

호출된 워크플로 내에서 secrets 컨텍스트를 사용하여 비밀을 참조할 수 있습니다.

참고

중첩된 재사용 가능한 워크플로에 비밀을 전달하는 경우 jobs.<job_id>.secrets을(를) 다시 사용하여 비밀을 전달해야 합니다. 자세한 내용은 워크플로 재사용을(를) 참조하세요.

호출자 워크플로가 호출된 워크플로에 지정되지 않은 비밀을 전달하면 오류가 발생합니다.

          `on.workflow_call.secrets`의 예

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.<secret_id>`

비밀과 연결할 문자열 식별자입니다.

`on.workflow_call.secrets.<secret_id>.required`

비밀을 제공해야 하는지 여부를 지정하는 부울입니다.

`on.workflow_run.<branches|branches-ignore>`

workflow_run 이벤트를 사용하는 경우 워크플로를 트리거하기 위해 트리거 워크플로를 실행해야 하는 분기를 지정할 수 있습니다.

          `branches` 및 `branches-ignore` 필터는 `*`, `**`, `+`, `?`, `!` 및 그 외 두 개 이상의 분기 이름에 대한 일치 판정을 위한 문자 등의 문자를 사용하는 GLOB 패턴을 허용합니다. 이름에 해당 문자가 포함되어 있고 리터럴 일치를 원하는 경우 각 특수 문자를 __ 로 `\`해야 합니다. glob 패턴에 대한 자세한 내용은 [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)을(를) 참조하세요.

예를 들어 다음 트리거가 있는 워크플로는 이름이 Build로 시작하는 분기에서 releases/라는 워크플로가 실행되는 경우에만 실행됩니다.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'

다음 트리거가 있는 워크플로는 이름이 Build가 아닌 분기에서 canary라는 워크플로가 실행되는 경우에만 실행됩니다.

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인 경우에는 그러지 않습니다.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

`on.workflow_dispatch`

workflow_dispatch 이벤트를 사용할 때 필요에 따라 워크플로에 전달되는 입력을 지정할 수 있습니다.

이 트리거는 워크플로 파일이 기본 브랜치에 있을 때만 이벤트를 수신합니다.

`on.workflow_dispatch.inputs`

트리거된 워크플로는 inputs 컨텍스트에서 입력을 받습니다. 자세한 내용은 컨텍스트를 참조하세요.

참고

워크플로는 github.event.inputs 컨텍스트의 입력도 수신합니다. inputs 컨텍스트와 github.event.inputs 컨텍스트의 정보는 inputs 컨텍스트가 부울 값을 문자열로 변환하는 대신 부울 값으로 유지한다는 점을 제외하고 동일합니다. 이 choice 형식은 문자열로 확인되며 단일 선택 가능한 옵션입니다.
최상위 속성 inputs 의 최대 수는 10 입니다.
최대 페이로드 inputs는 65,535자입니다.

          `on.workflow_dispatch.inputs`의 예

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.<input_id>.required`

입력을 제공해야 하는지 여부를 지정하는 부울입니다.

`on.workflow_dispatch.inputs.<input_id>.type`

이 매개 변수의 값은 입력의 데이터 형식을 지정하는 문자열입니다. boolean, choice, number, environment 또는 string 중 하나여야 합니다.

`permissions`

permissions를 사용하여 GITHUB_TOKEN에 부여된 기본 사용 권한을 수정하면 필요에 따라 액세스를 추가하거나 제거하여 필요한 최소 액세스만 허용할 수 있습니다. 자세한 내용은 워크플로에서 인증에 GITHUB_TOKEN 사용을(를) 참조하세요.

          `permissions`를 최상위 키로 사용하거나, 워크플로의 모든 작업에 적용하거나, 특정 작업 내에서 적용할 수 있습니다. 특정 작업 내에 `permissions` 키를 추가하면 `GITHUB_TOKEN`을 사용하는 해당 작업 내의 모든 동작 및 실행 명령이 지정한 액세스 권한을 얻게 됩니다. 자세한 내용은 [`jobs.<job_id>.permissions`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions)를 참조하세요.

조직의 소유자 또는 엔터프라이즈는 리포지토리 수준에서 GITHUB_TOKEN에 대한 쓰기 액세스를 제한할 수 있습니다. 자세한 정보는 조직에 대한 GitHub Actions 사용하지 않도록 설정 또는 제한 and 엔터프라이즈에서 GitHub Actions 대한 정책 적용을(를) 참조하세요.

워크플로가 pull_request_target 이벤트에 의해 트리거되면, GITHUB_TOKEN는 퍼블릭 포크에서 트리거되는 경우에도 읽기/쓰기 리포지토리 권한이 부여됩니다. 자세한 내용은 워크플로를 트리거하는 이벤트을(를) 참조하세요.

아래 표에 표시된 사용 가능한 각 권한에 대해 read(해당되는 경우) write 또는 none 액세스 수준 중 하나를 할당할 수 있습니다. write에는 read이(가) 포함됩니다. 이러한 권한에 대한 액세스를 지정하면 지정되지 않은 모든 권한은 none(으)로 설정됩니다.

사용 가능한 권한과 각 작업에서 수행할 수 있는 작업에 대한 세부 정보:

사용 권한	Allows an action using `GITHUB_TOKEN`을(를) 사용하여 작업을 허용합니다.
`actions`	GitHub Actions로 작업합니다. 예를 들어, `actions: write`에서 워크플로 실행을 취소하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`checks`	검사 실행 및 검사 도구 모음으로 작업합니다. 예를 들어, `checks: write`에서 작업이 검사 실행을 생성하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`contents`	리포지토리의 콘텐츠로 작업합니다. 예를 들어 `contents: read`에서는 작업이 커밋을 나열하도록 허용하고, `contents: write`에서는 작업이 릴리스를 만들 수 있도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`deployments`	배포를 통해 작업합니다. 예를 들어, `deployments: write`에서는 작업이 새 배포를 만들도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`discussions`	GitHub Discussion로 작업합니다. 예를 들어 `discussions: write`에서 작업이 토론을 종료하거나 삭제하도록 허용합니다. 자세한 내용은 토론에 GraphQL API 사용을(를) 참조하세요.
`issues`	문제로 작업합니다. 예를 들어 `issues: write`에서 작업이 문제에 주석을 추가하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`packages`	GitHub 패키지로 작업합니다. 예를 들어, `packages: write`에서 작업이 GitHub 패키지에 패키지를 업로드하고 게시하도록 허용합니다. 자세한 내용은 GitHub 패키지에 대한 사용 권한 정보을(를) 참조하세요.
`pages`	GitHub Pages로 작업합니다. 예를 들어 `pages: write`에서 작업이 GitHub Pages 빌드를 요청하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`pull-requests`	끌어오기 요청으로 작업합니다. 예를 들어 `pull-requests: write`에서 작업이 끌어오기 요청에 레이블을 추가하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`repository-projects`	GitHub 프로젝트(클래식)로 작업합니다. 예를 들어 `repository-projects: write`에서 작업이 프로젝트(클래식)에 열을 추가하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`security-events`	GitHub 코드 검사 경고로 작업합니다. 예를 들어 `security-events: read`에서 작업이 리포지토리에 대해 코드 검사 경고를 나열하도록 허용하고, `security-events: write`에서는 작업이 코드 검사 경고의 상태를 업데이트하도록 허용합니다. 자세한 내용은 '코드 검사 경고'에 대한 리포지토리 권한을 참조하세요. Dependabot 및 비밀 검사 경고는 이 권한으로는 읽을 수 없으며, GitHub 앱이나 personal access token이(가) 필요합니다. 자세한 내용은 'GitHub 앱에 필요한 사용 권한'에서 ‘Dependabot 경고’에 대한 리포지토리 권한 및 '코드 검사 경고'에 대한 리포지토리 권한을 참조하세요.
`statuses`	커밋 상태로 작업합니다. 예를 들어 `statuses:read`에서 작업이 지정된 참조에 대한 커밋 상태 나열하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.

          `GITHUB_TOKEN` 범위에 대한 액세스 정의

GITHUB_TOKEN 키 내에서 사용 가능한 권한의 값으로 read, write, none을 지정하여 permissions이 허용할 액세스를 정의할 수 있습니다.

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  discussions: read|write|none
  packages: read|write|none
  pages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

이러한 권한에 대한 액세스를 지정하면 지정되지 않은 모든 권한은 none으로 설정됩니다.

다음 구문을 사용하여 사용 가능한 모든 권한에 대한 read-all 또는 write-all 액세스 중 하나를 정의할 수 있습니다.

permissions: read-all

permissions: write-all

다음 구문을 사용하여 사용 가능한 모든 권한에 대한 사용 권한을 사용하지 않도록 설정할 수 있습니다.

permissions: {}

포크된 리포지토리의 권한 변경

또한 permissions 키를 사용하여 포크된 리포지토리에 대한 읽기 권한을 추가 및 제거할 수 있지만 일반적으로 쓰기 액세스 권한은 부여할 수 없습니다. 이 동작의 예외는 관리 사용자가 GitHub Actions 설정의 끌어오기 요청에서 워크플로에 쓰기 토큰 보내기 옵션을 선택한 경우입니다. 자세한 내용은 리포지토리에 대한 GitHub Actions 설정 관리을(를) 참조하세요.

워크플로 작업에 대한 사용 권한을 계산하는 방법

          `GITHUB_TOKEN`에 대한 권한은 처음에 엔터프라이즈, 조직 또는 리포지토리의 기본 설정으로 설정됩니다. 기본값이 이러한 수준에서 제한된 권한으로 설정된 경우 관련 리포지토리에 적용됩니다. 예를 들어 조직 수준에서 제한된 기본값을 선택하는 경우 해당 조직의 모든 리포지토리는 제한된 권한을 기본값으로 사용합니다. 그런 다음 워크플로 파일 내의 구성에 따라 먼저 워크플로 수준에서 그리고 작업 수준에서 차례로 권한을 조정합니다. 마지막으로 포크된 리포지토리가 아닌 `pull_request_target` 끌어오기 요청 이벤트에 의해 워크플로가 트리거되고 **끌어오기 요청 설정에서 워크플로에 쓰기 토큰 보내기** 가 선택되지 않은 경우 읽기 전용으로 쓰기 권한을 변경하도록 권한이 조정됩니다.

워크플로의 모든 작업에 대한 `GITHUB_TOKEN` 권한 설정

워크플로의 최상위 수준에서 permissions을(를) 지정하여 워크플로의 모든 작업에 설정이 적용되도록 할 수 있습니다.

예시: 전체 워크플로에 `GITHUB_TOKEN` 권한 설정

이 예제에서는 워크플로의 모든 작업에 적용되는 GITHUB_TOKEN에 대해 설정되는 사용 권한을 보여 줍니다. 모든 권한에는 읽기 액세스 권한이 부여됩니다.

name: "My workflow"

on: [ push ]

permissions: read-all

jobs:
  ...

포크된 리포지토리에 `permissions` 키 사용

또한 permissions 키를 사용하여 분기된 리포지토리에 대한 read 권한을 추가 및 제거할 수 있지만 일반적으로 write 액세스 권한은 부여할 수 없습니다. 이 동작에 대한 예외는 관리자가 설정의 끌어오기 요청 옵션에서 워크플로에 쓰기 토큰 보내기 옵션을 GitHub Actions 선택한 경우입니다. 자세한 내용은 리포지토리에 대한 GitHub Actions 설정 관리을(를) 참조하세요.

트리거된 워크플로 실행에 대한 Dependabot의 권한

Dependabot 끌어오기 요청에 의해 트리거되는 워크플로 실행은 포크된 리포지토리에서 온 것처럼 실행되므로 읽기 전용 GITHUB_TOKEN을 사용합니다. 이러한 워크플로 실행은 비밀에 액세스할 수 없습니다. 워크플로의 안전한 유지를 위한 전략의 자세한 내용은 안전 사용 참조을(를) 참조하세요.

`env`

워크플로의 모든 작업 단계에서 사용할 수 있는 map 변수. 단일 작업의 단계 또는 단일 단계에만 사용할 수 있는 변수를 설정할 수도 있습니다. 자세한 내용은 jobs.<job_id>.env 및 jobs.<job_id>.steps[*].env을(를) 참조하세요.

          `env` 맵의 변수는 맵의 다른 변수를 기준으로 정의할 수 없습니다.

둘 이상의 변수가 동일한 이름으로 정의되면 GitHub는 가장 구체적인 환경 변수를 사용합니다. 예를 들어 단계에 정의된 환경 변수는 단계가 실행되는 동안 동일한 이름의 작업 및 워크플로 환경 변수를 재정의합니다. 작업에 정의된 환경 변수는 작업이 실행되는 동안 동일한 이름의 워크플로 변수를 재정의합니다.

          `env`의 예

env:
  SERVER: production

`defaults`

defaults를 사용하여 워크플로의 모든 작업에 적용할 기본 설정의 map을 만듭니다. 작업에만 사용할 수 있는 기본 설정을 지정할 수도 있습니다. 자세한 내용은 jobs.<job_id>.defaults를 참조하세요.

둘 이상의 기본 설정이 동일한 이름으로 정의되면 GitHub는 가장 구체적인 기본 설정을 사용합니다. 예를 들어 작업에 정의된 기본 설정은 워크플로에 정의된 이름과 동일한 기본 설정을 재정의합니다.

`defaults.run`

defaults.run을 사용하여 워크플로의 모든 run 단계에 기본 shell 및 working-directory 옵션을 제공할 수 있습니다. 작업에만 사용할 수 있는 run에 대한 기본 설정을 지정할 수도 있습니다. 자세한 내용은 jobs.<job_id>.defaults.run를 참조하세요. 이 키워드에는 컨텍스트 또는 식을 사용할 수 없습니다.

예: 기본 셸 및 작업 디렉터리 설정

defaults:
  run:
    shell: bash
    working-directory: ./scripts

`defaults.run.shell`

shell을(를) 사용하여 단계의 shell을(를) 정의합니다. 키워드는 여러 컨텍스트를 참조할 수 있습니다. 자세한 내용은 컨텍스트를 참조하세요.

지원되는 플랫폼	`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}'"`.

`defaults.run.working-directory`

working-directory을(를) 사용하여 단계의 shell에 대한 작업 디렉터리를 정의합니다. 키워드는 여러 컨텍스트를 참조할 수 있습니다. 자세한 내용은 컨텍스트를 참조하세요.

팁

셸을 실행하기 전에 할당한 working-directory가 실행기에 존재하는지 확인합니다. 둘 이상의 기본 설정이 동일한 이름으로 정의되면 GitHub는 가장 구체적인 기본 설정을 사용합니다. 예를 들어 작업에 정의된 기본 설정은 워크플로에 정의된 이름과 동일한 기본 설정을 재정의합니다.

`concurrency`

concurrency를 사용하여 동일한 동시성 그룹을 사용하는 작업 또는 워크플로가 한 번에 하나만 실행되도록 합니다. 동시성 그룹은 모든 문자열 또는 식일 수 있습니다. 식은 github, inputs, vars컨텍스트만 사용할 수 있습니다. 식에 대한 자세한 내용은 워크플로 및 작업에서 식 평가을(를) 참조하세요.

작업 수준에서 concurrency를 지정할 수도 있습니다. 자세한 내용은 jobs.<job_id>.concurrency를 참조하세요.

다시 말해 동시성 그룹 하나에는 한 번에 실행 중인 작업 최대 한 개, 보류 중인 작업 최대 한 개만 있을 수 있습니다. 동시 작업 또는 워크플로가 큐에 대기 중인 경우 리포지토리의 동일한 동시성 그룹을 사용하는 다른 작업 또는 워크플로가 진행 중이면 대기 중인 작업 또는 워크플로는 pending 상태가 됩니다. 동일한 동시성 그룹에 있는 모든 기존 pending 작업 또는 워크플로가 있는 경우 취소되고 대기 중인 새 작업 또는 워크플로가 대신 수행됩니다.

동일한 동시성 그룹에서 현재 실행 중인 작업 또는 워크플로도 취소하려면 cancel-in-progress: true를 지정합니다. 동일한 동시성 그룹에서 현재 실행 중인 작업이나 워크플로를 조건부 취소하려면, 허용된 모든 식 컨텍스트에서 cancel-in-progress을(를) 식으로 지정하면 됩니다.

참고

동시성 그룹 이름은 대/소문자를 구분하지 않습니다. 예를 들어 prod 및 Prod는 동일한 동시성 그룹으로 처리됩니다.
동시성 그룹을 사용하는 작업 또는 워크플로 실행에 대해서는 순서가 보장되지 않습니다. 동일한 동시성 그룹에서 작업 또는 워크플로 실행은 임의의 순서로 처리됩니다.

예: 동시성 및 기본 동작 사용

GitHub Actions의 기본 동작은 여러 작업 또는 워크플로 실행이 동시에 실행되도록 하는 것입니다. concurrency 키워드를 사용하면 워크플로 실행의 동시성을 제어할 수 있습니다.

예를 들어 트리거 조건이 정의된 직후에 concurrency 키워드를 사용하면 특정 분기에 대한 전체 워크플로 실행의 동시성을 제한할 수 있습니다.

on:
  push:
    branches:
      - main

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

작업 수준에서 concurrency 키워드를 사용하여 워크플로 내에서 작업의 동시성을 제한할 수도 있습니다.

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 동시성 그룹에서 이미 진행 중인 동일한 작업의 실행이 취소됩니다.

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: staging_environment
      cancel-in-progress: true

또는 워크플로에서 동적 식(예: concurrency: ci-${{ github.ref }})을 사용하면 워크플로 또는 작업이 워크플로를 트리거한 분기 또는 태그의 참조 앞에 이름이 ci-인 동시성 그룹의 일부가 됩니다. 이 예제에서는 이전 실행이 진행 중인 동안 새 커밋이 기본 분기에 푸시되면 이전 실행이 취소되고 새 커밋이 시작됩니다.

on:
  push:
    branches:
      - main

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

예: 동시성을 사용하여 진행 중인 작업 또는 실행 취소

동시성을 사용하여 GitHub Actions에서 진행 중인 작업 또는 실행을 취소하려면 true로 설정된 cancel-in-progress 옵션을 통해 concurrency 키를 사용할 수 있습니다.

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

이 예제에서는 특정 동시성 그룹을 정의하지 않고 GitHub Actions은(는) 진행 중인 모든 작업 또는 워크플로 실행을 취소합니다.

예: 대체 값 사용

특정 이벤트에 대해서만 정의되는 속성으로 그룹 이름을 빌드하는 경우 대체 값을 사용할 수 있습니다. 예를 들어 github.head_ref는 pull_request 이벤트에서만 정의됩니다. 워크플로가 pull_request 이벤트 외에 다른 이벤트에도 응답하는 경우 구문 오류를 방지하기 위해 대체를 제공해야 합니다. 다음 동시성 그룹은 pull_request 이벤트에서만 진행 중인 작업 또는 실행을 취소합니다. github.head_ref가 정의되지 않은 경우 동시성 그룹은 실행에 고유하고 정의된 실행 ID로 대체됩니다.

concurrency:
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

예: 현재 워크플로에 대해서만 진행 중인 작업 또는 실행 취소

동일한 리포지토리에 여러 워크플로가 있는 경우 다른 워크플로에서 진행 중인 작업 또는 실행이 취소되지 않도록 워크플로 전체에서 동시성 그룹 이름이 고유해야 합니다. 그렇지 않으면 워크플로에 관계없이 이전에 진행 중이거나 보류 중인 작업이 취소됩니다.

동일한 워크플로의 진행 중인 실행만 취소하기 위해 github.workflow 속성을 사용하여 동시성 그룹을 빌드할 수 있습니다.

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

예: 특정 분기에서 진행 중인 작업만 취소

특정 분기에서 진행 중인 작업만 취소하고 나머지는 취소하지 않고자 하는 경우, cancel-in-progress을(를) 포함한 조건식을 사용하면 됩니다. 예를 들어 개발 분기에서만 진행 중인 작업을 취소하고 릴리스 분기에서는 취소하지 않으려면 이렇게 하면 됩니다.

릴리스 분기에서 실행 중이 아닌 경우 같은 워크플로의 진행 중인 실행만 취소하려면, 다음과 비슷한 식에 대하여 cancel-in-progress을(를) 설정하면 됩니다.

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ !contains(github.ref, 'release/')}}

이 예시에서는 release/1.2.3 분기에 대한 여러 푸시를 실행해도 진행 중인 실행을 취소하지 않습니다. main과(와) 같은 다른 분기로 푸시하면 진행 중인 실행이 취소됩니다.

`jobs`

워크플로 실행은 기본적으로 병렬로 실행되는 하나 이상의 jobs로 구성됩니다. 작업을 순차적으로 실행하려면 jobs.<job_id>.needs 키워드를 사용하여 다른 작업에 대한 종속성을 정의할 수 있습니다.

각 작업은 runs-on으로 지정된 실행기 환경에서 실행됩니다.

워크플로 사용량 한도 내에 있는 한 개수에 제한 없이 작업을 실행할 수 있습니다. 자세한 내용은GitHub에서 호스트되는 실행기 사용량 한도의 경우 청구 및 사용량, 자체 호스팅되는 실행기 사용량 한도의 경우 작업 제한을(를) 각각 참조하세요.

워크플로 실행에서 실행 중인 작업의 고유 식별자를 찾아야 하는 경우 GitHub API를 사용할 수 있습니다. 자세한 내용은 GitHub Actions의 REST API 엔드포인트을(를) 참조하세요.

`jobs.<job_id>`

jobs.<job_id>를 사용하여 작업에 고유 식별자를 지정합니다. job_id 키는 문자열이고 해당 값은 작업 구성 데이터 맵입니다. <job_id>를 jobs 개체에 고유한 문자열로 바꿔야 합니다. <job_id>는 문자 또는 _로 시작해야 하며 영숫자, - 또는 _만 포함해야 합니다.

예: 작업 만들기

이 예제에서는 두 개의 작업이 생성되었으며 해당 job_id 값은 my_first_job과 my_second_job입니다.

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

`jobs.<job_id>.name`

jobs.<job_id>.name을 사용하여 GitHub UI에 표시되는 작업 이름을 설정합니다.

`jobs.<job_id>.permissions`

특정 작업의 경우 jobs.<job_id>.permissions를 사용하여 GITHUB_TOKEN에 부여된 기본 사용 권한을 수정하면 필요에 따라 액세스를 추가하거나 제거하여 필요한 최소 액세스만 허용할 수 있습니다. 자세한 내용은 워크플로에서 인증에 GITHUB_TOKEN 사용을(를) 참조하세요.

작업 정의 내에서 사용 권한을 지정하여 필요한 경우 각 작업의 GITHUB_TOKEN에 대해 다른 사용 권한 집합을 구성할 수 있습니다. 또는 워크플로의 모든 작업에 대한 사용 권한을 지정할 수 있습니다. 워크플로 수준에서 사용 권한을 정의하는 방법에 대한 자세한 내용은 permissions를 참조하세요.

사용 가능한 권한과 각 작업에서 수행할 수 있는 작업에 대한 세부 정보:

사용 권한	Allows an action using `GITHUB_TOKEN`을(를) 사용하여 작업을 허용합니다.
`actions`	GitHub Actions로 작업합니다. 예를 들어, `actions: write`에서 워크플로 실행을 취소하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`checks`	검사 실행 및 검사 도구 모음으로 작업합니다. 예를 들어, `checks: write`에서 작업이 검사 실행을 생성하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`contents`	리포지토리의 콘텐츠로 작업합니다. 예를 들어 `contents: read`에서는 작업이 커밋을 나열하도록 허용하고, `contents: write`에서는 작업이 릴리스를 만들 수 있도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`deployments`	배포를 통해 작업합니다. 예를 들어, `deployments: write`에서는 작업이 새 배포를 만들도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`discussions`	GitHub Discussion로 작업합니다. 예를 들어 `discussions: write`에서 작업이 토론을 종료하거나 삭제하도록 허용합니다. 자세한 내용은 토론에 GraphQL API 사용을(를) 참조하세요.
`issues`	문제로 작업합니다. 예를 들어 `issues: write`에서 작업이 문제에 주석을 추가하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`packages`	GitHub 패키지로 작업합니다. 예를 들어, `packages: write`에서 작업이 GitHub 패키지에 패키지를 업로드하고 게시하도록 허용합니다. 자세한 내용은 GitHub 패키지에 대한 사용 권한 정보을(를) 참조하세요.
`pages`	GitHub Pages로 작업합니다. 예를 들어 `pages: write`에서 작업이 GitHub Pages 빌드를 요청하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`pull-requests`	끌어오기 요청으로 작업합니다. 예를 들어 `pull-requests: write`에서 작업이 끌어오기 요청에 레이블을 추가하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`repository-projects`	GitHub 프로젝트(클래식)로 작업합니다. 예를 들어 `repository-projects: write`에서 작업이 프로젝트(클래식)에 열을 추가하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.
`security-events`	GitHub 코드 검사 경고로 작업합니다. 예를 들어 `security-events: read`에서 작업이 리포지토리에 대해 코드 검사 경고를 나열하도록 허용하고, `security-events: write`에서는 작업이 코드 검사 경고의 상태를 업데이트하도록 허용합니다. 자세한 내용은 '코드 검사 경고'에 대한 리포지토리 권한을 참조하세요. Dependabot 및 비밀 검사 경고는 이 권한으로는 읽을 수 없으며, GitHub 앱이나 personal access token이(가) 필요합니다. 자세한 내용은 'GitHub 앱에 필요한 사용 권한'에서 ‘Dependabot 경고’에 대한 리포지토리 권한 및 '코드 검사 경고'에 대한 리포지토리 권한을 참조하세요.
`statuses`	커밋 상태로 작업합니다. 예를 들어 `statuses:read`에서 작업이 지정된 참조에 대한 커밋 상태 나열하도록 허용합니다. 자세한 내용은 GitHub 앱에 필요한 권한을(를) 참조하세요.

          `GITHUB_TOKEN` 범위에 대한 액세스 정의

GITHUB_TOKEN 키 내에서 사용 가능한 권한의 값으로 read, write, none을 지정하여 permissions이 허용할 액세스를 정의할 수 있습니다.

permissions:
  actions: read|write|none
  checks: read|write|none
  contents: read|write|none
  deployments: read|write|none
  issues: read|write|none
  discussions: read|write|none
  packages: read|write|none
  pages: read|write|none
  pull-requests: read|write|none
  repository-projects: read|write|none
  security-events: read|write|none
  statuses: read|write|none

이러한 권한에 대한 액세스를 지정하면 지정되지 않은 모든 권한은 none으로 설정됩니다.

다음 구문을 사용하여 사용 가능한 모든 권한에 대한 read-all 또는 write-all 액세스 중 하나를 정의할 수 있습니다.

permissions: read-all

permissions: write-all

다음 구문을 사용하여 사용 가능한 모든 권한에 대한 사용 권한을 사용하지 않도록 설정할 수 있습니다.

permissions: {}

포크된 리포지토리의 권한 변경

예: 워크플로에서 한 작업에 대한 `GITHUB_TOKEN` 권한 설정

이 예제에서는 이름이 stale로 지정된 작업에만 적용되는 GITHUB_TOKEN에 대해 설명되는 사용 권한을 보여 줍니다. issues 및 pull-requests 권한에 대한 쓰기 권한이 부여됩니다. 다른 모든 권한은 액세스할 수 없습니다.

jobs:
  stale:
    runs-on: ubuntu-latest

    permissions:
      issues: write
      pull-requests: write

    steps:
      - uses: actions/stale@v10

`jobs.<job_id>.needs`

이 작업이 실행되기 전에 완료해야 하는 작업을 식별하는 데 jobs.<job_id>.needs를 사용합니다. 문자열 또는 문자열 배열일 수 있습니다. 작업을 실패하거나 건너뛰게 되면 작업이 계속되도록 하는 조건식을 사용하지 않는 한 작업이 필요한 모든 작업을 건너뜁니다. 실행에 서로 필요한 일련의 작업이 포함된 경우 오류 또는 건너뛴 지점부터 종속성 체인의 모든 작업에 오류 및 건너뛰기가 적용됩니다. 종속된 작업이 성공하지 못한 경우에도 작업을 실행하려면 jobs.<job_id>.if에 always() 조건식을 사용합니다.

예: 성공적인 종속 작업 요구

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

이 예제에서 job1은 job2가 시작되기 전에 성공적으로 완료해야 하며 job3은 job1 및 job2 모두 완료되기를 기다립니다.

이 예제의 작업은 순차적으로 실행됩니다.

job1
job2
job3

예: 성공적인 종속 작업이 필요하지 않음

jobs:
  job1:
  job2:
    needs: job1
  job3:
    if: ${{ always() }}
    needs: [job1, job2]

이 예제에서 job3은 always() 조건식을 사용하여 성공 여부에 관계없이 job1 및 job2가 완료된 후에 항상 실행되도록 합니다. 자세한 내용은 워크플로 및 작업에서 식 평가을(를) 참조하세요.

`jobs.<job_id>.if`

jobs.<job_id>.if 조건부를 사용하여 조건이 충족되지 않는 한, 작업이 실행되지 않도록 할 수 있습니다. 지원되는 컨텍스트 및 식을 사용하여 조건을 만들 수 있습니다. 이 키에서 지원되는 컨텍스트에 대한 자세한 내용은 문맥 참조을(를) 참조하세요.

참고

jobs.<job_id>.strategy.matrix이 적용되기 전 jobs.<job_id>.if 상태로 평가합니다.

if 조건에서 식을 사용하는 경우, 선택에 따라 식 구문(${{ }})을 생략해도 됩니다. GitHub Actions에서 자동으로 if 조건을 식으로 평가하기 때문입니다. 그러나, 이 예외는 어디에나 적용되지는 않습니다.

${{ }} 식 구문을 사용하거나 !이 YAML 형식으로 예약된 표기법이므로 ! 식이 시작될 때 항상 '', "", () 이스케이프를 사용해야 합니다. 예시:

if: ${{ ! startsWith(github.ref, 'refs/tags/') }}

자세한 내용은 워크플로 및 작업에서 식 평가을(를) 참조하세요.

예: 특정 리포지토리에 대해서만 작업 실행

이 예제에서는 if를 사용하여 production-deploy 작업을 실행할 수 있는 시기를 제어합니다. 리포지토리 이름이 octo-repo-prod이고 octo-org 조직 내에 있는 경우에만 작업이 실행됩니다. 그렇지 않으면 작업이 ‘건너뛴 것’으로 표시됩니다.__

YAML

name: example-workflow
on: [push]
jobs:
  production-deploy:
    if: github.repository == 'octo-org/octo-repo-prod'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats

name: example-workflow
on: [push]
jobs:
  production-deploy:
    if: github.repository == 'octo-org/octo-repo-prod'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats

`jobs.<job_id>.runs-on`

jobs.<job_id>.runs-on을 사용하여 작업을 실행할 머신 형식을 정의합니다.

대상 머신은 자체 호스팅 러너일 수 있습니다.
할당된 레이블 또는 그룹 멤버 자격 또는 이러한 조합에 따라 러너를 대상으로 지정할 수 있습니다.
runs-on을(를) 다음으로 제공할 수 있습니다.
- 단일 문자열
- 문자열을 포함하는 단일 변수
- 문자열 배열 하나, 문자열이 포함된 변수 또는 둘 다의 조합
- group 또는 labels 키를 사용하는 key: value쌍
문자열 또는 변수 배열을 지정하면 워크플로가 지정된 모든 runs-on 값과 일치하는 실행기에서 실행됩니다. 예를 들어 여기서 작업은 linux, x64, gpu 레이블이 있는 자체 호스팅 실행기에서만 실행되며 다음을 수행합니다.
```
runs-on: [self-hosted, linux, x64, gpu]
```
자세한 내용은 자체 호스트 실행기 선택을 참조하세요.

배열 안에서 문자열과 변수를 혼합할 수 있습니다. 예시:

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.<job_id>.strategy를 사용합니다.

참고

self-hosted와 같은 단순한 문자열에는 따옴표가 필요하지 않지만, "${{ inputs.chosen-os }}"와 같은 식에는 따옴표가 필수입니다.

호스팅된 GitHub실행기 선택

참고

GitHub 호스트 실행기는 현재 GitHub Enterprise Server에서 지원되지 않습니다.

자체 호스팅 실행기 선택

작업에 대한 자체 호스팅 실행기를 지정하려면 자체 호스팅 실행기 레이블을 사용하여 워크플로 파일에서 runs-on을 구성합니다.

자체 호스팅 실행기에는 self-hosted 레이블이 있을 수 있습니다. 자체 호스트형 실행기를 설정할 때 기본적으로 self-hosted 레이블이 포함됩니다. 자체 호스트형 레이블이 적용되지 않도록 --no-default-labels 플래그를 전달할 수 있습니다. 레이블은 운영 체제 또는 아키텍처와 같은 실행기에 대한 타겟팅 옵션을 만드는 데 사용할 수 있으며, self-hosted로 시작하는 레이블 배열(먼저 나열해야 함)을 제공한 다음 필요에 따라 추가 레이블을 포함하는 것이 좋습니다. 레이블 배열을 지정하면 지정한 모든 레이블이 있는 실행기에서 작업이 큐에 대기됩니다.

참고

Actions Runner Controller는 self-hosted 레이블을 지원하지 않습니다.

예제: 실행기 선택에 레이블 사용

runs-on: [self-hosted, linux]

자세한 내용은 자체 호스팅 실행기 및 워크플로에서 자체 호스트형 런너 사용을(를) 참조하세요.

그룹 내에서 실행기 선택

실행기 그룹을 대상으로 지정하여 해당 그룹의 멤버인 모든 실행기에서 작업이 실행되도록 runs-on을(를) 사용할 수 있습니다. 보다 세분화된 컨트롤을 위해 실행기 그룹을 레이블과 결합할 수 있습니다.

예시: 그룹을 사용하여 작업 실행 위치 제어

이 예제에서는 Ubuntu 실행기라는 ubuntu-runners 그룹에 추가되었습니다. runs-on 키는 ubuntu-runners 그룹에서 사용 가능한 모든 실행기로 작업을 보냅니다.

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: 
      group: ubuntu-runners
    steps:
      - uses: actions/checkout@v5
      - 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와 결합되어 작업이 일치하는 레이블이 있는 그룹 내에서 사용 가능한 모든 실행기로 라우팅됩니다.

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on:
      group: ubuntu-runners
      labels: ubuntu-24.04-16core
    steps:
      - uses: actions/checkout@v5
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

예: 접두사를 사용하여 실행기 그룹 구분

예를 들어 조직에서 명명된 실행기 그룹 my-group과 엔터프라이즈에 이름이 다른 실행기 그룹 my-group가 있는 경우 워크플로 파일을 업데이트하여 org/my-group 또는 ent/my-group를 사용하여 두 그룹을 구분할 수 있습니다.

org/사용:

runs-on:
  group: org/my-group
  labels: [ self-hosted, label-1 ]

ent/사용:

runs-on:
  group: ent/my-group
  labels: [ self-hosted, label-1 ]

`jobs.<job_id>.environment`

jobs.<job_id>.environment를 사용하여 작업에서 참조하는 환경을 정의합니다.

환경을 환경 name만으로 제공하거나 name 및 url을 사용하여 환경 개체로 제공할 수 있습니다. URL은 배포 API에서 environment_url에 매핑됩니다. 배포 API에 대한 자세한 내용은 리포지토리에 대한 REST API 엔드포인트을(를) 참조하세요.

참고

환경을 참조하는 작업이 실행기로 전송되기 전에 모든 배포 보호 규칙이 전달되어야 합니다. 자세한 내용은 배포 환경 관리을(를) 참조하세요.

예: 단일 환경 이름 사용

environment: staging_environment

예: 환경 이름 및 URL 사용

environment:
  name: production_environment
  url: https://github.com

url의 값은 식이 될 수 있습니다. 허용되는 언어 식 컨텍스트: github, inputs, vars, needs, strategy, matrix, job, runner, env 및 steps. 식에 대한 자세한 내용은 워크플로 및 작업에서 식 평가을(를) 참조하세요.

예: 출력을 URL로 사용

environment:
  name: production_environment
  url: ${{ steps.step_id.outputs.url_output }}

name의 값은 식이 될 수 있습니다. 허용되는 언어 식 컨텍스트: github, inputs, vars, needs, strategy, matrix. 식에 대한 자세한 내용은 워크플로 및 작업에서 식 평가을(를) 참조하세요.

예: 환경 이름을 식으로 사용

environment:
  name: ${{ github.ref_name }}

`jobs.<job_id>.concurrency`

jobs.<job_id>.concurrency를 사용하여 동일한 동시성 그룹을 사용하는 단일 작업 또는 워크플로만 한 번에 실행되도록 할 수 있습니다. 동시성 그룹은 모든 문자열 또는 식일 수 있습니다. 허용되는 언어 식 컨텍스트: github, inputs, vars, needs, strategy, matrix. 식에 대한 자세한 내용은 워크플로 및 작업에서 식 평가을(를) 참조하세요.

워크플로 수준에서 concurrency를 지정할 수도 있습니다. 자세한 내용은 concurrency를 참조하세요.

참고

동시성 그룹 이름은 대/소문자를 구분하지 않습니다. 예를 들어 prod 및 Prod는 동일한 동시성 그룹으로 처리됩니다.
동시성 그룹을 사용하는 작업 또는 워크플로 실행에 대해서는 순서가 보장되지 않습니다. 동일한 동시성 그룹에서 작업 또는 워크플로 실행은 임의의 순서로 처리됩니다.

예: 동시성 및 기본 동작 사용

예를 들어 트리거 조건이 정의된 직후에 concurrency 키워드를 사용하면 특정 분기에 대한 전체 워크플로 실행의 동시성을 제한할 수 있습니다.

on:
  push:
    branches:
      - main

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

작업 수준에서 concurrency 키워드를 사용하여 워크플로 내에서 작업의 동시성을 제한할 수도 있습니다.

on:
  push:
    branches:
      - main

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: example-group
      cancel-in-progress: true

예: 동시성 그룹

동시성 그룹은 워크플로 실행 또는 동일한 동시성 키를 공유하는 작업의 실행을 관리하고 제한하는 방법을 제시합니다.

워크플로 또는 작업이 동시성 그룹의 일부가 되도록 워크플로에서 동시성 조건을 정의할 수 있습니다.

jobs:
  job-1:
    runs-on: ubuntu-latest
    concurrency:
      group: staging_environment
      cancel-in-progress: true

on:
  push:
    branches:
      - main

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

예: 동시성을 사용하여 진행 중인 작업 또는 실행 취소

concurrency:
  group: ${{ github.ref }}
  cancel-in-progress: true

이 예제에서는 특정 동시성 그룹을 정의하지 않고 GitHub Actions은(는) 진행 중인 모든 작업 또는 워크플로 실행을 취소합니다.

예: 대체 값 사용

concurrency:
  group: ${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

예: 현재 워크플로에 대해서만 진행 중인 작업 또는 실행 취소

동일한 워크플로의 진행 중인 실행만 취소하기 위해 github.workflow 속성을 사용하여 동시성 그룹을 빌드할 수 있습니다.

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

예: 특정 분기에서 진행 중인 작업만 취소

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ !contains(github.ref, 'release/')}}

`jobs.<job_id>.outputs`

jobs.<job_id>.outputs를 사용하여 작업 출력의 map을 만들 수 있습니다. 작업 출력은 이 작업에 의존하는 모든 다운스트림 작업에 사용할 수 있습니다. 작업 종속성 정의에 대한 자세한 내용은 jobs.<job_id>.needs를 참조하세요.

작업당 출력 크기는 최대 1MB입니다. 워크플로 실행의 모든 출력 합계는 최대 50MB가 될 수 있습니다. 크기는 UTF-16 인코딩을 기준으로 추정됩니다.

식을 포함하는 작업 출력은 각 작업의 끝에 있는 실행기에서 평가됩니다. 비밀이 포함된 출력은 실행기에서 수정되며 GitHub Actions로 보내지 않습니다.

출력에 비밀이 포함될 수 있으므로 “비밀이 포함될 수 있으므로 출력 {output.Key}를 건너뜁니다.”와 같은 경고 메시지가 표시됩니다. 비밀을 처리하는 방법에 대한 자세한 내용은 예시: 작업 또는 워크플로 간에 비밀 마스킹 및 전달을 참조하세요.

종속 작업에서 작업 출력을 사용하려면 needs 컨텍스트를 사용할 수 있습니다. 자세한 내용은 문맥 참조을(를) 참조하세요.

예: 작업 출력 정의

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"

행렬형 작업에서 작업 출력 사용

행렬형은 서로 다른 이름의 여러 출력을 생성하는 데 사용할 수 있습니다. 행렬형을 사용하는 경우 행렬형 내의 모든 작업에서 작업 출력이 결합됩니다.

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) }}'

경고

작업은 행렬형 작업이 실행되는 순서를 보장하지 않습니다. 출력 이름이 고유한지 확인하고, 그렇지 않으면 실행되는 마지막 행렬형 작업이 출력 값을 재정의합니다.

`jobs.<job_id>.env`

작업의 모든 단계에서 사용할 수 있는 map 변수. 전체 워크플로 또는 개별 단계에 변수를 설정할 수도 있습니다. 자세한 내용은 env 및 jobs.<job_id>.steps[*].env을(를) 참조하세요.

          `jobs.<job_id>.env`의 예

jobs:
  job1:
    env:
      FIRST_NAME: Mona

`jobs.<job_id>.defaults`

jobs.<job_id>.defaults를 사용하여 작업의 모든 단계에 적용할 기본 설정의 map을 만듭니다. 전체 워크플로에 대한 기본 설정을 지정할 수도 있습니다. 자세한 내용은 defaults를 참조하세요.

`jobs.<job_id>.defaults.run`

jobs.<job_id>.defaults.run을(를) 사용하여 작업의 모든 run 단계에 기본값 shell 및 working-directory를 제공합니다.

작업의 모든 run 단계에 기본 shell및working-directory 옵션을 제공할 수 있습니다. 전체 워크플로에 대한 run의 기본 설정을 지정할 수도 있습니다. 자세한 내용은 defaults.run를 참조하세요.

이러한 경고는 jobs.<job_id>.defaults.run 및 jobs.<job_id>.steps[*].run 수준에서 재정의할 수 있습니다.

`jobs.<job_id>.defaults.run.shell`

shell을(를) 사용하여 단계의 shell을(를) 정의합니다. 키워드는 여러 컨텍스트를 참조할 수 있습니다. 자세한 내용은 컨텍스트를 참조하세요.

지원되는 플랫폼	`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}'"`.

`jobs.<job_id>.defaults.run.working-directory`

팁

예: 작업에 대한 기본 `run` 단계 옵션 설정

jobs:
  job1:
    runs-on: ubuntu-latest
    defaults:
      run:
        shell: bash
        working-directory: ./scripts

`jobs.<job_id>.steps`

작업에는 steps라는 일련의 작업이 포함됩니다. 단계에 따라 퍼블릭 리포지토리에서 명령을 실행하거나, 설치 작업을 실행하거나, 또는 Docker 레지스트리에 게시된 작업에서 작업을 실행할 수 있습니다. 모든 단계가 작업을 실행하는 것은 아니지만 모든 작업은 한 단계로 실행됩니다. 각 단계는 실행기 환경에서 자체 프로세스로 실행되며 작업 영역 및 파일 시스템에 액세스할 수 있습니다. 단계가 자체 프로세스에서 실행되므로 여러 단계 간에는 환경 변수에 대한 변경 내용이 유지되지 않습니다. GitHub 에서는 작업을 설정하고 완료하는 기본 제공 단계를 제공합니다.

          GitHub 처음 1,000개의 검사만 표시합니다. 그러나 워크플로 사용량 한도 내에 있는 한 무제한의 단계를 실행할 수 있습니다. 자세한 내용은 [AUTOTITLE](/actions/learn-github-actions/usage-limits-billing-and-administration)에서 GitHub-호스팅 실행기에 대한 정보를, [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners)에서 자체 호스팅 실행기 사용 제한에 대한 정보를 참조하세요.

          `jobs.<job_id>.steps`의 예

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.<job_id>.steps[*].id`

단계의 고유 식별자입니다. id를 사용하여 컨텍스트에서 단계를 참조할 수 있습니다. 자세한 내용은 문맥 참조을(를) 참조하세요.

`jobs.<job_id>.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인 경우에만 실행됩니다.

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)을(를) 참조하세요.

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 }} 비밀을 참조하는 식의 반환 값은 빈 문자열이 됩니다.

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.'

자세한 내용은 문맥 참조 및 GitHub Actions에서 비밀 사용을(를) 참조하세요.

`jobs.<job_id>.steps[*].name`

          GitHub에 표시할 단계의 이름입니다.

`jobs.<job_id>.steps[*].uses`

작업 단계의 일부로 실행할 작업을 선택합니다. 작업은 재사용 가능한 코드 단위입니다. 워크플로와 동일한 리포지토리, 퍼블릭 리포지토리 또는 게시된 Docker 컨테이너 이미지에 정의된 작업을 사용할 수 있습니다.

Git 참조, SHA 또는 Docker 태그를 지정하여 사용 중인 작업의 버전을 포함하는 것이 좋습니다. 버전을 지정하지 않으면 작업 소유자가 업데이트를 게시할 때 워크플로가 중단되거나 예기치 않은 동작이 발생할 수 있습니다.

릴리스된 작업 버전의 커밋 SHA를 사용하는 것이 안정성 및 보안 측면에서 가장 안전합니다.
작업이 주 버전 태그를 게시하는 경우 호환성을 유지하면서 중요한 수정 및 보안 패치를 받아야 합니다. 이 동작은 작업 작성자의 재량에 따라 결정됩니다.
작업의 기본 분기를 사용하는 것이 편리할 수 있지만 다른 사용자가 호환성이 손상되는 변경으로 새 주 버전을 릴리스하는 경우 워크플로가 중단될 수 있습니다.

일부 작업에는 with 키워드를 사용하여 설정해야 하는 입력이 필요합니다. 작업의 추가 정보 파일을 검토하여 필요한 입력을 확인합니다.

작업은 JavaScript 파일 또는 Docker 컨테이너입니다. 사용 중인 작업이 Docker 컨테이너인 경우 Linux 환경에서 작업을 실행해야 합니다. 자세한 내용은 runs-on을(를) 참조하세요.

예제: 버전이 지정된 작업 사용

steps:
  # Reference a specific commit
  - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3
  # Reference the major version of a release
  - uses: actions/checkout@v5
  # Reference a specific version
  - uses: actions/checkout@v5.2.0
  # Reference a branch
  - uses: actions/checkout@main

예제: 퍼블릭 작업 사용

{owner}/{repo}@{ref}

공용 GitHub 리포지토리에서 분기, ref 또는 SHA를 지정할 수 있습니다.

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 저장소에 있는 하위 디렉터리입니다.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: actions/aws/ec2@main

예제: 워크플로와 동일한 리포지토리에서 작업 사용

./path/to/dir

워크플로 리포지토리의 작업이 포함된 디렉터리의 경로입니다. 작업을 사용하기 전에 리포지토리를 체크 아웃해야 합니다.

리포지토리 파일 구조 예시:

|-- hello-world (repository)
|   |__ .github
|       └── workflows
|           └── my-first-workflow.yml
|       └── actions
|           |__ hello-world-action
|               └── action.yml

경로는 기본 작업 디렉터리(github.workspace, $GITHUB_WORKSPACE)에 대해 상대적(./) 경로입니다. 작업이 리포지토리를 워크플로와 다른 위치로 검사하는 경우 로컬 작업에 사용되는 상대 경로를 업데이트해야 합니다.

워크플로 파일 예시:

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@v5
      # 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 이미지입니다.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://alpine:3.8

예제: Docker 퍼블릭 레지스트리 작업 사용

docker://{host}/{image}:{tag}

퍼블릭 레지스트리의 Docker 이미지입니다. 이 예제에서는 gcr.io에서 Google Container Registry를 사용합니다.

jobs:
  my_first_job:
    steps:
      - name: My first step
        uses: docker://gcr.io/cloud-builders/gradle

예제: 워크플로와 다른 프라이빗 리포지토리 내에서 작업 사용

워크플로는 프라이빗 리포지토리를 체크 아웃하고 작업을 로컬로 참조해야 합니다. 토큰을 personal access token 생성하고 비밀로 추가합니다. 자세한 내용은 개인용 액세스 토큰 관리 및 GitHub Actions에서 비밀 사용을(를) 참조하세요.

예제에서 PERSONAL_ACCESS_TOKEN을 비밀 이름으로 바꿉니다.

jobs:
  my_first_job:
    steps:
      - name: Check out repository
        uses: actions/checkout@v5
        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 대신 사용할 수 있습니다. 자세한 내용은 [AUTOTITLE](/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow)을(를) 참조하세요.

`jobs.<job_id>.steps[*].run`

운영 체제의 셸을 사용하여 21,000자를 초과하지 않는 명령줄 프로그램을 실행합니다. name을 입력하지 않으면 단계 이름은 기본적으로 run 명령에 지정된 텍스트로 설정됩니다.

명령은 기본적으로 로그인하지 않는 셸을 사용하여 실행됩니다. 다른 셸을 선택하고 명령을 실행하는 데 사용되는 셸을 사용자 지정할 수 있습니다. 자세한 내용은 jobs.<job_id>.steps[*].shell을(를) 참조하세요.

각 run 키워드는 실행기 환경의 새 프로세스 및 셸을 나타냅니다. 다중 선 명령을 제공하면 각 선이 동일한 셸에서 실행됩니다. 예를 들면 다음과 같습니다.

단일 선 명령:

- name: Install Dependencies
  run: npm install

다중 선 명령:

- name: Clean install dependencies and build
  run: |
    npm ci
    npm run build

`jobs.<job_id>.steps[*].working-directory`

          `working-directory` 키워드를 사용하여 명령을 실행할 위치의 작업 디렉터리를 지정할 수 있습니다.

- name: Clean temp directory
  run: rm -rf *
  working-directory: ./temp

또는 작업의 모든 run 단계나 전체 워크플로의 모든 run 단계에 대해 기본 작업 디렉터리를 지정할 수 있습니다. 자세한 내용은 defaults.run.working-directory 및 jobs.<job_id>.defaults.run.working-directory을(를) 참조하세요.

스크립트를 run 단계를 사용하여 실행할 수도 있습니다. 자세한 내용은 워크플로에 스크립트 추가을(를) 참조하세요.

`jobs.<job_id>.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 및 jobs.<job_id>.defaults.run.shell을(를) 참조하세요.

예제: Bash를 사용하여 스크립트 실행

steps:
  - name: Display the path
    shell: bash
    run: echo $PATH

예제: Windows를 사용하는 명령 실행`cmd`

steps:
  - name: Display the path
    shell: cmd
    run: echo %PATH%

예제: PowerShell Core를 사용하는 명령 실행

steps:
  - name: Display the path
    shell: pwsh
    run: echo ${env:PATH}

예제: PowerShell Desktop을 사용하여 명령 실행

steps:
  - name: Display the path
    shell: powershell
    run: echo ${env:PATH}

예제: 인라인 Python 스크립트 실행

steps:
  - name: Display the path
    shell: python
    run: |
      import os
      print(os.environ['PATH'])

사용자 지정 셸

          `shell`를 사용하여 `command [options] {0} [more_options]` 값을 템플릿 문자열로 설정할 수 있습니다. 
          GitHub 는 문자열의 첫 번째 공백으로 구분된 단어를 명령으로 해석하고 임시 스크립트의 파일 이름을 삽입 `{0}`합니다.

예를 들면 다음과 같습니다.

steps:
  - name: Display the environment variables and their values
    shell: perl {0}
    run: |
      print %ENV

이 예제에서 사용된 perl 명령을 실행기에 설치해야 합니다.

종료 코드 및 오류 작업 기본 설정

기본 제공 셸 키워드의 경우 호스트된 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.<job_id>.steps[*].with`

작업에 정의된 입력 매개 변수의 map입니다. 각 입력 매개 변수는 키/값 쌍입니다. 입력 매개 변수는 환경 변수로 설정됩니다. 변수가 INPUT_접두어로 추가되고 대문자로 변환됩니다.

Docker 컨테이너에 대해 정의된 입력 매개 변수는 args을(를) 사용해야 합니다. 자세한 내용은 jobs.<job_id>.steps[*].with.args을(를) 참조하세요.

          `jobs.<job_id>.steps[*].with`의 예

          `first_name` 작업에 정의된 세 개의 입력 매개 변수(`middle_name`, `last_name`, `hello_world`)를 정의합니다. 입력 변수는 `hello-world` 작업에서 `INPUT_FIRST_NAME`, `INPUT_MIDDLE_NAME`, `INPUT_LAST_NAME` 환경 변수에서 액세스할 수 있습니다.

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.<job_id>.steps[*].with.args`

Docker 컨테이너에 대한 입력을 정의하는 string입니다. GitHub 는 컨테이너가 시작할 때 args 을/를 그것의 ENTRYPOINT 에 전달합니다. 이 매개 변수는 array of strings를 지원하지 않습니다. 공백을 포함하는 단일 인수는 큰따옴표 ""로 묶어야 합니다.

          `jobs.<job_id>.steps[*].with.args`의 예

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`를 사용하는 경우 기본 설정에 따라 정렬된 지침을 사용합니다.

작업의 README에서 필요한 인수를 문서화하고 CMD 명령에서 생략합니다.
어떤 args도 지정하지 않고 작업을 사용할 수 있는 기본값을 사용합니다.
작업이 --help 플래그 또는 이와 유사한 항목을 노출하는 경우 이를 기본값으로 사용하여 작업을 자체 문서화합니다.

`jobs.<job_id>.steps[*].with.entrypoint`

          `ENTRYPOINT`의 Docker `Dockerfile`를 재정의하거나 아직 지정하지 않은 경우 설정합니다. 셸 및 exec 형식인 Docker `ENTRYPOINT` 명령과 달리 `entrypoint` 키워드는 실행될 실행 파일을 정의하는 단일 문자열만 허용합니다.

          `jobs.<job_id>.steps[*].with.entrypoint`의 예

steps:
  - name: Run a custom command
    uses: octo-org/action-name@main
    with:
      entrypoint: /a/different/executable

          `entrypoint` 키워드는 Docker 컨테이너 작업에 사용되어야 하지만 입력을 정의하지 않는 JavaScript 작업에 사용할 수도 있습니다.

`jobs.<job_id>.steps[*].env`

실행기 환경에서 사용할 단계에 대한 변수를 설정합니다. 전체 워크플로 또는 하나의 작업에 대해 변수를 설정할 수도 있습니다. 자세한 내용은 env 및 jobs.<job_id>.env을(를) 참조하세요.

퍼블릭 작업은 README 파일에서 예상되는 변수를 지정할 수 있습니다. 암호 또는 토큰과 같은 비밀 또는 중요한 값을 설정하는 경우 secrets 컨텍스트를 사용하여 비밀을 설정해야 합니다. 자세한 내용은 문맥 참조을(를) 참조하세요.

          `jobs.<job_id>.steps[*].env`의 예

steps:
  - name: My first action
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      FIRST_NAME: Mona
      LAST_NAME: Octocat

`jobs.<job_id>.steps[*].continue-on-error`

단계가 실패해도 작업이 실패하지 않도록 방지합니다. 이 단계가 실패해도 작업이 통과되도록 true로 설정합니다.

`jobs.<job_id>.steps[*].timeout-minutes`

프로세스를 종료하기 전에 단계를 실행할 최대 시간(분)입니다. 최대값: GitHub로 호스팅 및 자체 호스팅 실행기 모두에 대해 360입니다.

소수 값은 지원되지 않습니다. timeout-minutes은(는) 양의 정수여야 합니다.

`jobs.<job_id>.timeout-minutes`

작업을 자동으로 취소하기 전에 GitHub의 최대 실행 시간(분)입니다. 기본값: 360

시간 제한이 실행기의 작업 실행 시간 제한을 초과하는 경우 실행 시간 한도에 다다르면 작업이 취소됩니다. 작업 실행 시간 제한에 대한 자세한 내용은 GitHub-호스팅 실행기에 대한 청구 및 사용량 및 자체 호스팅 실행기 사용 제한에 대한 작업 제한을 참조하세요.

참고

          `GITHUB_TOKEN`은 작업이 완료되거나 최대 24시간 후에 만료됩니다. 자체 호스팅 실행기에서 작업 시간 제한이 24시간보다 큰 경우 토큰이 제한 요인이 될 수 있습니다.

          `GITHUB_TOKEN`에 대한 자세한 내용은 [AUTOTITLE](/actions/security-guides/automatic-token-authentication#about-the-github_token-secret)을(를) 참조하세요.

`jobs.<job_id>.strategy`

          `jobs.<job_id>.strategy`를 사용하여 작업에 행렬 전략을 사용합니다. 
          매트릭스 전략을 사용하면 단일 작업 정의에서 변수를 사용하여 변수의 조합을 기반으로 하는 여러 작업 실행을 자동으로 만들 수 있습니다. 예를 들어 매트릭스 전략을 사용하여 여러 버전의 언어 또는 여러 운영 체제에서 코드를 테스트할 수 있습니다. 자세한 내용은 [AUTOTITLE](/actions/using-jobs/using-a-matrix-for-your-jobs)을 참조하세요.

`jobs.<job_id>.strategy.matrix`

          `jobs.<job_id>.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의 현재 값에 액세스할 수 있습니다. 자세한 내용은 문맥 참조을(를) 참조하세요.

기본적으로 GitHub 실행기 가용성에 따라 병렬로 실행되는 작업 수를 최대화합니다. 행렬의 변수 순서에 따라 작업이 생성되는 순서가 결정됩니다. 정의한 첫 번째 변수는 워크플로 실행에서 만든 첫 번째 작업이 됩니다.

1차원 매트릭스 사용

예를 들어 다음 워크플로는 version 값을 사용하여 [10, 12, 14] 변수를 정의합니다. 워크플로는 변수의 각 값에 대해 하나씩 3개의 작업을 실행합니다. 각 작업은 version 컨텍스트를 통해 matrix.version 값에 액세스하고 해당 값을 node-version 작업에 actions/setup-node으로 전달합니다.

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 작업에 전달합니다.

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개의 작업을 생성합니다.

matrix:
  os:
    - ubuntu-latest
    - macos-latest
  node:
    - version: 14
    - version: 20
      env: NODE_OPTIONS=--openssl-legacy-provider

매트릭스의 각 작업에는 아래와 같이 os 및 node 값의 고유한 조합이 있습니다.

- 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.<job_id>.strategy.matrix.include`

          `include` 목록의 각 개체에서 키:값 쌍이 원래 행렬 값을 덮어쓰지 않으면 개체의 키:값 쌍이 각 행렬 조합에 추가됩니다. 개체를 행렬 조합에 추가할 수 없는 경우 대신 새 행렬 조합이 만들어집니다. 원래 행렬 값은 덮어쓰는 것이 아니라 추가된 행렬 값을 덮어쓸 수 있습니다.

예: 구성 확장

예를 들어, 다음 워크플로는 os 및 node의 각 조합에 대해 하나씩 4개의 작업을 실행합니다. windows-latest의 os 값과 16의 node 값에 대한 작업이 실행되면 6 값을 사용하는 npm이라는 추가 변수가 작업에 포함됩니다.

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 값에 대한 작업을 실행합니다.

jobs:
  example_matrix:
    strategy:
      matrix:
        os: [macos-latest, windows-latest, ubuntu-latest]
        version: [12, 14, 16]
        include:
          - os: windows-latest
            version: 17

매트릭스 변수를 지정하지 않으면 include 아래의 모든 구성이 실행됩니다. 예를 들어 다음 워크플로는 각 include 항목에 대해 하나씩 두 개의 작업을 실행합니다. 이렇게 하면 완전히 채워진 매트릭스 없이 매트릭스 전략을 활용할 수 있습니다.

jobs:
  includes_only:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        include:
          - site: "production"
            datacenter: "site-a"
          - site: "staging"
            datacenter: "site-b"

`jobs.<job_id>.strategy.matrix.exclude`

제외된 구성은 제외되려면 부분 일치여야 합니다.

모든 include 조합은 exclude 다음에 처리됩니다. include를 사용하여 이전에 제외된 조합을 다시 추가하는 데 사용할 수 있습니다.

`jobs.<job_id>.strategy.fail-fast`

jobs.<job_id>.strategy.fail-fast 및 jobs.<job_id>.continue-on-error로 작업 오류를 처리하는 방법을 제어할 수 있습니다.

jobs.<job_id>.strategy.fail-fast는 전체 행렬에 적용됩니다. jobs.<job_id>.strategy.fail-fast가 true로 설정되거나 식이 true로 평가되면 GitHub는 행렬의 작업이 실패할 경우 행렬의 진행 중인 작업과 대기 중인 작업을 모두 취소합니다. 이 속성은 기본적으로 true입니다.

jobs.<job_id>.continue-on-error는 단일 작업에 적용됩니다. jobs.<job_id>.continue-on-error가 true인 경우 jobs.<job_id>.continue-on-error: true인 작업이 실패하더라도 행렬의 다른 작업은 계속 실행됩니다.

jobs.<job_id>.strategy.fail-fast 및 jobs.<job_id>.continue-on-error를 함께 사용할 수 있습니다. 예를 들어 다음 워크플로는 4개의 작업을 시작합니다. 각 작업에 대해 continue-on-error는 matrix.experimental 값으로 결정됩니다. continue-on-error: false인 작업이 실패하면 진행 중이거나 큐에 대기 중인 모든 작업이 취소됩니다. continue-on-error: true인 작업이 실패하면 다른 작업은 영향을 받지 않습니다.

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.<job_id>.strategy.max-parallel`

기본적으로 GitHub 실행기 가용성에 따라 병렬로 실행되는 작업 수를 최대화합니다.

`jobs.<job_id>.continue-on-error`

          `jobs.<job_id>.continue-on-error`은(는) 단일 작업에 적용됩니다. 
          `jobs.<job_id>.continue-on-error`가 `true`인 경우 `jobs.<job_id>.continue-on-error: true`인 작업이 실패하더라도 행렬의 다른 작업은 계속 실행됩니다.

작업이 실패해도 워크플로 실행이 실패하지 않도록 방지합니다. 이 작업이 실패해도 워크플로 실행이 통과하도록 true로 설정합니다.

예제: 특정 실패 매트릭스 작업으로 인해 워크플로 실행에 실패하지 않도록 방지

워크플로 실행에 실패하지 않고 작업 행렬의 특정 작업이 실패하도록 허용할 수 있습니다. 예를 들어 워크플로 실행에 실패하지 않도록 node가 15로 설정된 실험 작업만 실패하도록 허용하려는 경우입니다.

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.<job_id>.container`

참고

워크플로에서 Docker 컨테이너 작업, 작업 컨테이너, 서비스 컨테이너를 사용하는 경우, Linux 실행기를 사용해야 합니다.

GitHub에서 호스트되는 실행기를 사용하는 경우 Ubuntu 실행기를 사용해야 합니다.
자체 호스팅 실행기를 사용하는 경우 실행기로 Linux 컴퓨터를 사용해야 하며 Docker를 설치해야 합니다.

jobs.<job_id>.container를 사용하여 컨테이너를 아직 지정하지 않은 작업에서 모든 단계를 실행하는 컨테이너를 만듭니다. 스크립트 및 컨테이너 작업을 둘 다 사용하는 단계가 있는 경우 컨테이너 작업은 동일한 볼륨 탑재가 있는 동일한 네트워크에서 형제 컨테이너로 실행됩니다.

container를 설정하지 않으면 단계가 컨테이너에서 실행되도록 구성된 작업을 참조하지 않는 한, 모든 단계가 runs-on으로 지정된 호스트에서 직접 실행됩니다.

참고

컨테이너 내의 run 단계에 대한 기본 셸은 bash가 아니라 sh입니다. 이 셸은 jobs.<job_id>.defaults.run 또는 jobs.<job_id>.steps[*].shell로 재정의할 수 있습니다.

예: 컨테이너 내에서 작업 실행

YAML

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)

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 키워드를 생략해도 됩니다.

jobs:
  container-test-job:
    runs-on: ubuntu-latest
    container: node:18

`jobs.<job_id>.container.image`

jobs.<job_id>.container.image를 사용하여 작업을 실행하기 위한 컨테이너로 사용할 Docker 이미지를 정의합니다. 값은 Docker Hub 이미지 이름 또는 레지스트리 이름일 수 있습니다.

참고

Docker Hub는 일반적으로 자체 호스팅 러너에서 작업에 영향을 미치는 밀어넣기 및 끌어오기 작업 모두에 속도 제한을 적용합니다. 그러나 GitHub 호스팅 러너는 GitHub 및 Docker 간의 규약에 따라 이러한 제한을 받지 않습니다.

`jobs.<job_id>.container.credentials`

이미지의 컨테이너 레지스트리에서 이미지를 끌어오기 위해 인증이 필요한 경우 jobs.<job_id>.container.credentials를 사용하여 username 및 password의 map을 설정할 수 있습니다. 자격 증명은 docker login 명령에 제공하는 것과 동일한 값입니다.

예: 컨테이너 레지스트리에 대한 자격 증명 정의

container:
  image: ghcr.io/owner/image
  credentials:
     username: ${{ github.actor }}
     password: ${{ secrets.github_token }}

`jobs.<job_id>.container.env`

jobs.<job_id>.container.env를 사용하여 컨테이너에서 환경 변수의 map을 설정합니다.

`jobs.<job_id>.container.ports`

jobs.<job_id>.container.ports를 사용하여 컨테이너에 노출할 포트의 array를 설정합니다.

`jobs.<job_id>.container.volumes`

jobs.<job_id>.container.volumes를 사용하여 서비스 컨테이너에서 사용할 볼륨의 array를 설정합니다. 볼륨을 사용하여 서비스 또는 작업의 여러 단계 간에 데이터를 공유할 수 있습니다. 명명된 Docker 볼륨, 익명 Docker 볼륨 또는 호스트의 바인딩 탑재를 지정할 수 있습니다.

볼륨을 지정하려면 원본 및 대상 경로를 지정합니다.

<source>:<destinationPath>입니다.

<source>는 호스트 컴퓨터의 볼륨 이름 또는 절대 경로이며 <destinationPath>는 컨테이너의 절대 경로입니다.

예제: 컨테이너에 볼륨 탑재

volumes:
  - my_docker_volume:/volume_mount
  - /data/my_data
  - /source/directory:/destination/directory

`jobs.<job_id>.container.options`

jobs.<job_id>.container.options를 사용하여 추가 Docker 컨테이너 리소스 옵션을 구성합니다. 옵션 목록은 docker create 옵션을 참조하세요.

경고

--network 및 --entrypoint 옵션은 지원되지 않습니다.

`jobs.<job_id>.services`

참고

워크플로에서 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.<service_name>.ports}} 설정합니다. 이 예제에서는 및${{ job.services.nginx.ports['80'] }}컨텍스트를 사용하여 서비스 호스트 포트에 ${{ job.services.redis.ports['6379'] }} 액세스할 수 있습니다.

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.<job_id>.services.<service_id>.image`

작업을 실행하기 위해 서비스 컨테이너로 사용할 Docker 이미지입니다. 값은 Docker Hub 이미지 이름 또는 레지스트리 이름일 수 있습니다.

          `jobs.<job_id>.services.<service_id>.image`에 빈 문자열이 할당되면 서비스가 시작되지 않습니다. 이를 사용해 다음 예시와 유사한 조건부 서비스를 설정할 수 있습니다.

services:
  nginx:
    image: ${{ options.nginx == true && 'nginx' || '' }}

`jobs.<job_id>.services.<service_id>.credentials`

          `jobs.<job_id>.services.<service_id>.credentials`의 예

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.<job_id>.services.<service_id>.env`

서비스 컨테이너의 map 환경 변수를 설정합니다.

`jobs.<job_id>.services.<service_id>.ports`

서비스 컨테이너에 노출할 포트의 array를 설정합니다.

`jobs.<job_id>.services.<service_id>.volumes`

사용할 서비스 컨테이너에 대한 볼륨의 array를 설정합니다. 볼륨을 사용하여 서비스 또는 작업의 여러 단계 간에 데이터를 공유할 수 있습니다. 명명된 Docker 볼륨, 익명 Docker 볼륨 또는 호스트의 바인딩 탑재를 지정할 수 있습니다.

볼륨을 지정하려면 원본 및 대상 경로를 지정합니다.

          `<source>:<destinationPath>`;

          `<source>`는 호스트 컴퓨터의 볼륨 이름 또는 절대 경로이며 `<destinationPath>`는 컨테이너의 절대 경로입니다.

          `jobs.<job_id>.services.<service_id>.volumes`의 예

volumes:
  - my_docker_volume:/volume_mount
  - /data/my_data
  - /source/directory:/destination/directory

`jobs.<job_id>.services.<service_id>.options`

추가 Docker 컨테이너 리소스 옵션입니다. 옵션 목록은 docker create 옵션을 참조하세요.

경고

          `--network` 옵션은 지원되지 않습니다.

`jobs.<job_id>.uses`

작업으로 실행할 재사용 가능한 워크플로 파일의 위치 및 버전입니다. 다음 구문 중 하나를 사용하십시오.

퍼블릭, 내부, 프라이빗 리포지토리에서 재사용 가능한 워크플로의 경우 {owner}/{repo}/.github/workflows/{filename}@{ref}입니다.
동일한 리포지토리에서 다시 사용할 수 있는 워크플로의 경우 ./.github/workflows/{filename}입니다.

첫 번째 선택에서 {ref}은(는) SHA, 릴리스 태그 또는 분기 이름을 사용할 수 있습니다. 릴리스 태그와 분기의 이름이 같으면 릴리스 태그가 분기 이름보다 우선합니다. 안정성과 보안을 위해서는 커밋 SHA를 사용하는 것이 가장 안전합니다. 자세한 내용은 안전 사용 참조을(를) 참조하세요.

두 번째 구문 옵션({owner}/{repo}, @{ref} 없음)을 사용하는 경우 호출된 워크플로는 호출자 워크플로와 동일한 커밋에서 가져옵니다. refs/heads, refs/tags 등의 참조 접두사는 사용할 수 없습니다. 이 키워드에는 컨텍스트 또는 식을 사용할 수 없습니다.

          `jobs.<job_id>.uses`의 예

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

자세한 내용은 워크플로 재사용을(를) 참조하세요.

`jobs.<job_id>.with`

작업을 사용하여 재사용 가능한 워크플로를 호출하는 경우 with사용하여 워크플로에 전달되는 입력 맵을 제공할 수 있습니다.

전달하는 모든 입력은 호출된 워크플로에 정의된 입력 사양과 일치해야 합니다.

          [
          `jobs.<job_id>.steps[*].with`
          ](#jobsjob_idstepswith)와는 달리, `jobs.<job_id>.with`을(를) 통해 전달하는 입력은 호출된 워크플로에서 환경 변수로 사용할 수 없습니다. 대신 `inputs` 컨텍스트를 사용하여 입력을 참조할 수 있습니다.

          `jobs.<job_id>.with`의 예

jobs:
  call-workflow:
    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main
    with:
      username: mona

`jobs.<job_id>.with.<input_id>`

입력 및 입력 값에 대한 문자열 식별자로 구성된 쌍입니다. 호출된 워크플로의 on.workflow_call.inputs.<inputs_id>에 정의된 입력의 이름과 식별자가 일치해야 합니다. 호출된 워크플로의 on.workflow_call.inputs.<input_id>.type에 정의된 형식과 값의 데이터 형식이 일치해야 합니다.

허용되는 언어 식 컨텍스트: github및 needs

`jobs.<job_id>.secrets`

작업을 사용하여 재사용 가능한 워크플로를 호출하는 경우 secrets를 사용하여 호출된 워크플로에 전달되는 비밀 맵을 제공할 수 있습니다.

전달하는 모든 비밀은 호출된 워크플로에 정의된 이름과 일치해야 합니다.

          `jobs.<job_id>.secrets`의 예

jobs:
  call-workflow:
    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main
    secrets:
      access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}

`jobs.<job_id>.secrets.inherit`

          `inherit` 키워드를 사용하여 호출 워크플로의 모든 비밀을 호출된 워크플로에 전달합니다. 여기에는 호출 워크플로가 액세스할 수 있는 모든 비밀, 즉 조직, 리포지토리, 환경 비밀이 포함됩니다. 
          `inherit` 키워드는 동일한 조직 내의 리포지토리 또는 동일한 엔터프라이즈 내의 조직 간에 비밀을 전달하는 데 사용할 수 있습니다.

          `jobs.<job_id>.secrets.inherit`의 예

on:
  workflow_dispatch:

jobs:
  pass-secrets-to-workflow:
    uses: ./.github/workflows/called-workflow.yml
    secrets: inherit

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.<job_id>.secrets.<secret_id>`

비밀의 문자열 식별자와 비밀 값으로 구성된 쌍입니다. 호출된 워크플로의 on.workflow_call.secrets.<secret_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) 및/또는 `[`가 포함된 패턴이 있는 `]`를 사용하는 경우 패턴은 따옴표로 묶어야 합니다.

# 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.<push>.<branches|tags>, on.<pull_request>.<branches|tags>, 및 on.<push|pull_request>.paths을(를) 참조하세요.

분기 및 태그와 일치하는 패턴

패턴	설명	일치하는 예제
`feature/*`

          `*` 와일드카드는 문자와 일치하지만 슬래시(`/`)와는 일치하지 않습니다.                                                                                                      | `feature/my-branch`<br/><br/>`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`<br/><br/>`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 |