변수 정보
변수는 민감하지 않은 구성 정보를 저장하고 다시 사용하는 방법을 제공합니다. 컴파일러 플래그, 사용자 이름 또는 서버 이름과 같은 구성 데이터를 변수로 저장할 수 있습니다. 변수는 워크플로를 실행하는 실행기 컴퓨터에서 보간됩니다. 작업 또는 워크플로 단계에서 실행되는 명령은 변수를 만들고, 읽고, 수정할 수 있습니다.
고유한 사용자 지정 변수를 설정하거나 GitHub이(가) 자동으로 설정하는 기본 환경 변수를 사용할 수 있습니다. 자세한 내용은 "기본 환경 변수"를 참조하세요.
두 가지 방법으로 사용자 지정 변수를 설정할 수 있습니다.
- 단일 워크플로에서 사용할 환경 변수를 정의하려면 워크플로 파일에서
env
키를 사용할 수 있습니다. 자세한 내용은 "단일 워크플로에 대한 환경 변수 정의"를 참조하세요. - 여러 워크플로에서 사용할 구성 변수를 정의하고 조직, 리포지토리 또는 환경 수준에서 정의할 수있습니다. 자세한 내용은 "여러 워크플로에 대한 구성 변수 정의"를 참조하세요.
경고: 기본적으로 변수는 빌드 출력에서 마스크 해제된 상태로 렌더링됩니다. 암호와 같은 중요한 정보에 대한 보안 강화가 필요한 경우 대신 비밀을 사용합니다. 자세한 내용은 "GitHub Actions에서 비밀 사용" 항목을 참조하세요.
단일 워크플로에 대한 환경 변수 정의
단일 워크플로에 대한 사용자 지정 환경 변수를 정의하려면 워크플로 파일에서 env
키를 사용하여 정의할 수 있습니다. 이 메서드로 설정한 사용자 지정 환경 변수의 범위는 정의된 요소로 제한됩니다. 다음과 같이 범위가 지정된 변수를 정의할 수 있습니다.
- 전체 워크플로(워크플로 파일의 최상위 수준에서
env
를 사용하여) - 워크플로 내 작업의 컨텐츠(
jobs.<job_id>.env
를 사용하여) - 작업 내의 특정 단계(
jobs.<job_id>.steps[*].env
를 사용하여)
name: Greeting on variable day on: workflow_dispatch env: DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona
name: Greeting on variable day
on:
workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
실행기 환경 변수를 사용하거나 컨텍스트를 사용하여 env
변수 값에 액세스할 수 있습니다. 위의 예시에서는 echo
명령, 즉 $DAY_OF_WEEK
, $Greeting
및 $First_Name
에 실행기 환경 변수로 사용되는 세 가지 사용자 지정 변수를 보여줍니다. 해당 변수의 값은 각각 워크플로, 작업 및 단계 수준에서 설정되고 범위가 지정됩니다. 이러한 변수의 보간은 실행기에서 발생합니다.
워크플로 단계 run
의 명령 또는 참조된 작업은 실행기에서 사용 중인 셸에서 처리됩니다. 워크플로의 다른 부분에 있는 명령은 GitHub Actions에 의해 처리되며 실행기로 전송되지 않습니다. 실행기 환경 변수 또는 컨텍스트를 run
단계에서 사용할 수 있지만, 실행기로 전송되지 않은 워크플로 부분에서는 컨텍스트를 사용하여 변수 값에 액세스해야 합니다. 자세한 내용은 "컨텍스트를 사용하여 변수 값에 액세스"를 참조하세요.
워크플로 작업이 실행기 컴퓨터로 전송된 후 실행기 환경 변수 보간이 수행되므로 실행기에서 사용되는 셸에 적절한 구문을 사용해야 합니다. 이 예시에서 워크플로는 ubuntu-latest
를 지정합니다. 기본적으로 Linux 실행기는 bash 셸을 사용하므로 $NAME
구문을 사용해야 합니다. 기본적으로 Windows 실행기는 PowerShell을 사용하므로 $env:NAME
구문을 사용합니다. 셸에 대한 자세한 내용은 "GitHub Actions에 대한 워크플로 구문" 항목을 참조하세요.
환경 변수의 명명 규칙
환경 변수를 설정하는 경우 기본 환경 변수 이름을 사용할 수 없습니다. 기본 환경 변수의 전체 목록은 아래의 "기본 환경 변수"를 참조하세요. 이러한 기본 변수 중 하나의 값을 재정의하려고 하면 할당이 무시됩니다.
참고: 단계에서 run: env
를 사용한 다음 단계의 출력을 검사하여 워크플로 단계에서 사용할 수 있는 전체 환경 변수 집합을 나열할 수 있습니다.
여러 워크플로에 대한 구성 변수 정의하기
참고: GitHub Actions에 대한 구성 변수는 beta 버전이며 변경될 수 있습니다.
여러 워크플로에서 사용할 구성 변수를 만들고 조직, 리포지토리 또는 환경 수준에서 정의할 수있습니다.
예를 들어, 구성 변수를 사용하여 조직 수준에서 도구를 빌드하기 위해 전달된 매개 변수의 기본값을 설정한 다음 리포지토리 소유자가 사례별로 이러한 매개 변수를 재정의하도록 허용할 수 있습니다.
구성 변수를 정의하면 vars
컨텍스트에서 자동으로 구성 변수를 사용할 수 있습니다. 자세한 내용은 "vars
컨텍스트를 사용하여 구성 변수 값에 액세스하기"를 참조하세요.
구성 변수 우선 참조
이름이 같은 변수가 여러 수준에 있는 경우 가장 낮은 수준의 변수가 우선적으로 참조됩니다. 예를 들어, 조직 수준 변수의 이름이 리포지토리 수준 변수와 동일한 경우 리포지토리 수준 변수가 우선 참조됩니다. 마찬가지로 조직, 리포지토리 및 환경 모두에 이름이 같은 변수가 있는 경우 환경 수준 변수가 우선 참조됩니다.
재사용 가능한 워크플로의 경우 호출자 워크플로 리포지토리의 변수가 사용됩니다. 호출된 워크플로를 포함하는 리포지토리의 변수는 호출자 워크플로에서 사용할 수 없습니다.
구성 변수에 대한 명명 규칙
구성 변수 이름에는 다음 규칙이 적용됩니다.
- 비밀 이름에는 영숫자 문자(
[a-z]
,[A-Z]
,[0-9]
) 또는 밑줄(_
)만 사용할 수 있습니다. 공백은 사용할 수 없습니다. - 비밀 이름은
GITHUB_
접두사로 시작할 수 없습니다. - 비밀 이름은 숫자로 시작할 수 없습니다.
- 이름은 대/소문자를 구분하지 않습니다.
- 비밀 이름은 해당 수준에서 고유해야 합니다.
리포지토리에 대한 구성 변수 만들기
리포지토리 소유자만 개인 계정 리포지토리의 GitHub에 비밀 또는 변수를 만들 수 있습니다. admin
액세스 권한이 있는 사용자만 조직 리포지토리에 대한 에 비밀 또는 변수를 만들 수 있습니다. 마지막으로, 협력자 액세스 권한이 있는 사용자만 REST API를 통해 개인 계정 리포지토리 또는 조직 리포지토리에 대한 비밀 또는 변수를 만들 수 있습니다.
-
GitHub에서 리포지토리의 기본 페이지로 이동합니다.
-
리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.
-
사이드바의 "보안" 섹션에서 비밀 및 변수를 선택하고 작업을 클릭합니다.
-
변수 탭을 클릭합니다.
-
새 리포지토리 변수를 클릭합니다.
-
이름 필드에 변수의 이름을 입력합니다.
-
값 필드에 변수 값을 입력합니다.
-
변수 추가를 클릭합니다.
환경에 대한 구성 변수 만들기
개인 계정 리포지토리에서 환경에 대한 비밀 또는 변수를 만들려면 리포지토리 소유자여야 합니다. 조직 리포지토리에서 환경에 대한 비밀 또는 변수를 만들려면 admin
액세스 권한이 있어야 합니다. 환경에 대한 자세한 내용은 "배포 환경 관리"을 참조하세요.
-
GitHub에서 리포지토리의 기본 페이지로 이동합니다.
-
리포지토리 이름 아래에서 Settings(설정)를 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.
-
왼쪽 사이드바에서 환경을 클릭합니다.
-
변수를 추가할 환경을 클릭합니다.
-
환경 변수에서 변수 추가를 클릭합니다.
-
이름 필드에 변수의 이름을 입력합니다.
-
값 필드에 변수 값을 입력합니다.
-
변수 추가를 클릭합니다.
조직에 대한 구성 변수 만들기
조직에서 비밀 또는 변수를 만들 때, 정책을 사용하여 리포지토리별로 액세스를 제한할 수 있습니다. 예를 들어 모든 리포지토리에 대한 액세스 권한을 부여하거나 프라이빗 리포지토리 또는 지정된 리포지토리 목록에 대해서만 액세스를 제한할 수 있습니다.
조직 소유자 및 "조직 작업 변수 관리" 또는 "조직 작업 비밀 관리" 권한을 가진 사용자는 조직 수준에서 비밀 또는 변수를 만들 수 있습니다.
자세한 내용은 "사용자 지정 조직 역할 소개"을 참조하세요.
-
GitHub에서 조직의 기본 페이지로 이동합니다.
-
조직 이름에서 설정을 클릭합니다. "설정" 탭이 표시되지 않으면 드롭다운 메뉴를 선택한 다음 설정을 클릭합니다.
-
사이드바의 "보안" 섹션에서 비밀 및 변수를 선택하고 작업을 클릭합니다.
-
변수 탭을 클릭합니다.
참고: "Actions 비밀 및 변수" 페이지에는 사용 권한에 따라 비밀 및 변수에 대한 고유한 탭이 표시되지 않을 수 있습니다. "조직 Actions 변수 관리" 및 "조직 Actions 비밀 관리" 권한이 있는 조직 소유자 및 사용자에게는 변수 및 비밀 탭이 표시됩니다. 자세한 내용은 "사용자 지정 조직 역할 소개"을(를) 참조하세요.
-
새 조직 변수를 클릭합니다.
-
이름 필드에 변수의 이름을 입력합니다.
-
값 필드에 변수 값을 입력합니다.
-
리포지토리 액세스 드롭다운 목록에서 액세스 정책을 선택합니다.
-
변수 추가를 클릭합니다.
구성 변수에 대한 제한
개별 변수의 크기는 48KB로 제한됩니다.
최대 1,000개의 조직 변수, 리포지토리당 500개의 변수, 환경당 100개의 변수를 저장할 수 있습니다. 조직 및 리포지토리 변수의 총 결합 크기 제한은 워크플로 실행당 256KB입니다.
리포지토리에서 만든 워크플로는 다음과 같은 수의 변수에 액세스할 수 있습니다.
- 리포지토리 변수의 총 크기가 256KB 미만인 경우 최대 500개의 리포지토리 변수. 리포지토리 변수의 총 크기가 256KB를 초과하는 경우, 해당 제한에 미치지 않는 리포지토리 변수만 사용할 수 있습니다(변수 이름으로 사전순 정렬).
- 리포지토리 및 조직 변수의 총 결합 크기가 256KB 미만인 경우 최대 1,000개의 조직 변수. 조직 및 리포지토리 변수의 총 결합 크기가 256KB를 초과하는 경우, 해당 제한에 미치지 않는 조직 변수만 사용할 수 있습니다(리포지토리 변수를 고려한 후 변수 이름으로 사전순 정렬).
- 최대 100개의 환경 수준 변수.
참고: 환경 수준 변수는 256KB의 총 크기 제한에 포함되지 않습니다. 리포지토리 및 조직 변수의 결합된 크기 제한을 초과하고 추가 변수가 필요한 경우, 환경을 사용하고 환경에서 추가 변수를 정의할 수 있습니다.
컨텍스트를 사용하여 변수 값에 액세스하기
컨텍스트는 워크플로 실행, 변수, 실행기 환경, 작업 및 단계에 대한 정보에 액세스하는 방법입니다. 자세한 내용은 "워크플로 실행에 대한 컨텍스트 정보에 액세스" 항목을 참조하세요. 워크플로에서 다양한 용도로 사용할 수 있는 다른 많은 컨텍스트가 있습니다. 워크플로 내에서 특정 컨텍스트를 사용할 수 있는 위치에 대한 자세한 내용은 "워크플로 실행에 대한 컨텍스트 정보에 액세스" 항목을 참조하세요.
env
컨텍스트}를 사용하고 환경 변수 값에 액세스하고 vars
컨텍스트를 사용하여 구성 변수 값에 액세스할 수 있습니다.
env
컨텍스트를 사용하여 환경 변수 값에 액세스하기
실행기 환경 변수 외에도 GitHub Actions을(를) 사용하면 컨텍스트로 env
키 값을 설정하고 읽을 수 있습니다. 환경 변수 및 컨텍스트는 워크플로의 여러 지점에서 사용하기 위한 것입니다.
워크플로 또는 참조된 작업의 run
단계는 실행기에서 처리됩니다. 따라서 실행기에서 사용 중인 셸에 대한 적절한 구문(예시: Linux 실행기의 bash 셸에는 $NAME
, Windows 실행기의 PowerShell에는 $env:NAME
)을 사용하여 여기에서 실행기 환경 변수를 사용할 수 있습니다. 대부분의 경우 ${{ CONTEXT.PROPERTY }}
구문과 함께 컨텍스트를 사용하여 동일한 값에 액세스할 수도 있습니다. 차이점은 작업이 실행기로 전송되기 전에 컨텍스트가 보간되고 문자열로 대체된다는 것입니다.
그러나 GitHub Actions에 의해 처리되고 실행기로 전송되지 않는 워크플로의 일부에서는 실행기 환경 변수를 사용할 수 없습니다. 대신 컨텍스트를 사용해야 합니다. 예를 들어 작업 또는 단계가 실행기로 전송되는지 여부를 결정하는 if
조건이 항상 GitHub Actions에 의해 처리됩니다. 따라서 if
조건문의 컨텍스트를 사용하여 변수의 값에 액세스해야 합니다.
name: Conditional env variable on: workflow_dispatch env: DAY_OF_WEEK: Monday jobs: greeting_job: runs-on: ubuntu-latest env: Greeting: Hello steps: - name: "Say Hello Mona it's Monday" if: ${{ env.DAY_OF_WEEK == 'Monday' }} run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!" env: First_Name: Mona
name: Conditional env variable
on: workflow_dispatch
env:
DAY_OF_WEEK: Monday
jobs:
greeting_job:
runs-on: ubuntu-latest
env:
Greeting: Hello
steps:
- name: "Say Hello Mona it's Monday"
if: ${{ env.DAY_OF_WEEK == 'Monday' }}
run: echo "$Greeting $First_Name. Today is $DAY_OF_WEEK!"
env:
First_Name: Mona
이전 예시에서는 이렇게 수정하여 if
조건부를 도입했습니다. 워크플로 단계는 이제 DAY_OF_WEEK
가 "월요일"로 설정된 경우에만 실행됩니다. env
컨텍스트를 사용하여 if
조건문에서 이 값에 액세스합니다. run
명령 내에서 참조되는 변수에는 env
컨텍스트가 필요하지 않습니다. 이는 실행기 환경 변수로 참조되며 실행기에서 작업을 받은 후 보간됩니다. 그러나 컨텍스트를 사용하여 작업을 실행기로 보내기 전에 해당 변수를 보간하도록 선택할 수 있습니다. 결과 출력은 동일합니다.
run: echo "${{ env.Greeting }} ${{ env.First_Name }}. Today is ${{ env.DAY_OF_WEEK }}!"
참고: 컨텍스트는 일반적으로 ${{ context.property }}
와 같이 달러 기호와 중괄호를 사용하여 표시됩니다. if
조건에서 ${{
및 }}
은(는) 선택 사항이지만, 사용하는 경우 위와 같이 전체 비교 문을 묶어야 합니다.
실행기에 작업을 보내기 전에 처리되는 워크플로의 일부에서 변수 값에 액세스하기 위해 보통 env
또는 github
컨텍스트를 사용합니다.
Context | 사용 사례 | 예시 |
---|---|---|
env | 워크플로에 정의된 사용자 지정 변수를 참조합니다. | ${{ env.MY_VARIABLE }} |
github | 워크플로 실행 및 실행을 트리거한 이벤트에 대한 정보를 참조합니다. | ${{ github.repository }} |
경고: 워크플로 및 작업을 만들 때 코드가 가능한 공격자의 신뢰할 수 없는 입력을 실행할 수 있는지 항상 고려해야 합니다. 공격자가 자신의 악성 콘텐츠를 삽입할 수 있으므로 특정 컨텍스트는 신뢰할 수 없는 입력으로 처리되어야 합니다. 자세한 내용은 "GitHub Actions에 대한 보안 강화"을(를) 참조하세요.
vars
컨텍스트를 사용하여 구성 변수 값에 액세스하기
vars
컨텍스트를 사용하여 워크플로 전체에서 구성 변수에 액세스할 수 있습니다. 자세한 내용은 "워크플로 실행에 대한 컨텍스트 정보에 액세스" 항목을 참조하세요.
구성 변수가 설정되지 않은 경우, 변수를 참조하는 컨텍스트는 빈 문자열을 반환합니다.
다음 예제는 워크플로 전체에서 vars
컨텍스트와 함께 구성 변수를 사용하는 방법을 나타냅니다. 다음 각각의 구성 변수는 리포지토리, 조직 또는 환경 수준에서 정의되었습니다.
on: workflow_dispatch: env: # Setting an environment variable with the value of a configuration variable env_var: ${{ vars.ENV_CONTEXT_VAR }} jobs: display-variables: name: ${{ vars.JOB_NAME }} # You can use configuration variables with the `vars` context for dynamic jobs if: ${{ vars.USE_VARIABLES == 'true' }} runs-on: ${{ vars.RUNNER }} environment: ${{ vars.ENVIRONMENT_STAGE }} steps: - name: Use variables run: | echo "repository variable : $REPOSITORY_VAR" echo "organization variable : $ORGANIZATION_VAR" echo "overridden variable : $OVERRIDE_VAR" echo "variable from shell environment : $env_var" env: REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }} ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }} OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }} - name: ${{ vars.HELLO_WORLD_STEP }} if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }} uses: actions/hello-world-javascript-action@main with: who-to-greet: ${{ vars.GREET_NAME }}
on:
workflow_dispatch:
env:
# Setting an environment variable with the value of a configuration variable
env_var: ${{ vars.ENV_CONTEXT_VAR }}
jobs:
display-variables:
name: ${{ vars.JOB_NAME }}
# You can use configuration variables with the `vars` context for dynamic jobs
if: ${{ vars.USE_VARIABLES == 'true' }}
runs-on: ${{ vars.RUNNER }}
environment: ${{ vars.ENVIRONMENT_STAGE }}
steps:
- name: Use variables
run: |
echo "repository variable : $REPOSITORY_VAR"
echo "organization variable : $ORGANIZATION_VAR"
echo "overridden variable : $OVERRIDE_VAR"
echo "variable from shell environment : $env_var"
env:
REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }}
ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }}
OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }}
- name: ${{ vars.HELLO_WORLD_STEP }}
if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }}
uses: actions/hello-world-javascript-action@main
with:
who-to-greet: ${{ vars.GREET_NAME }}
기본 환경 변수
GitHub 집합의 기본 환경 변수는 워크플로의 모든 단계에서 사용할 수 있습니다.
기본 환경 변수는 GitHub에 의해 설정되고 워크플로에 정의되지 않으므로 env
컨텍스트를 통해 액세스할 수 없습니다. 그러나 대부분의 기본 변수에는 그에 상응하는 비슷한 이름의 컨텍스트 속성이 있습니다. 예를 들어 ${{ github.ref }}
컨텍스트 속성을 사용하여 워크플로를 처리하는 동안 GITHUB_REF
변수의 값을 읽을 수 있습니다.
GITHUB_*
및 RUNNER_*
(으)로 명명된 기본 환경 변수의 값에 덮어쓸 수 없습니다. 현재 변수 값을 CI
(으)로 덮어쓸 수 있습니다. 그러나, 이것이 항상 가능할 것이라고 보장되지는 않습니다. 환경 변수 설정에 대한 자세한 내용은 "단일 워크플로에 대해 환경 변수 정의하기" 및 "GitHub Actions에 대한 워크플로 명령" 항목을 참조하세요.
작업에서는 하드 코딩된 파일 경로를 사용하는 대신 변수를 사용하여 파일 시스템에 액세스하는 것이 좋습니다. GitHub은(는) 모든 실행기 환경에서 사용할 작업에 대한 변수를 설정합니다.
변수 | 설명 |
---|---|
CI | 항상 true (으)로 설정합니다. |
GITHUB_ACTION | 현재 실행 중인 작업의 이름 또는 단계의 id 입니다. 예를 들어 작업의 경우 __repo-owner_name-of-action-repo 입니다.GitHub은(는) 특수 문자를 제거하고 현재 단계에서 스크립트를 실행할 때 id 없이 __run 이름을 사용합니다. 동일한 작업에서 동일한 스크립트 또는 작업을 두 번 이상 사용하는 경우 밑줄 앞에 오는 시퀀스 번호로 구성된 접미사가 이름에 포함됩니다. 예를 들어 실행하는 첫 번째 스크립트에는 이름이 __run 으로 지정되고 두 번째 스크립트의 이름은 __run_2 로 지정됩니다. 마찬가지로 두 번째 actions/checkout 호출은 actionscheckout2 입니다. |
GITHUB_ACTION_PATH | 작업이 있는 경로입니다. 이 속성은 복합 작업에서만 지원됩니다. 이 경로를 사용하여 작업이 있는 디렉터리를 변경하고 동일한 리포지토리에 있는 다른 파일에 액세스할 수 있습니다. 예들 들어 /home/runner/work/_actions/repo-owner/name-of-action-repo/v1 입니다. |
GITHUB_ACTION_REPOSITORY | 작업을 실행하는 단계의 경우 작업의 소유자 및 리포지토리 이름입니다. 예들 들어 actions/checkout 입니다. |
GITHUB_ACTIONS | GitHub Actions이(가) 워크플로를 실행하는 경우 항상 true 로 설정됩니다. 이 변수를 사용하여 테스트가 로컬로 실행되는 경우와 GitHub Actions(으)로 실행되는 경우를 구분할 수 있습니다. |
GITHUB_ACTOR | 워크플로를 시작한 사용자 또는 앱의 이름입니다. 예들 들어 octocat 입니다. |
GITHUB_ACTOR_ID | 최초로 워크플로 실행을 트리거한 사용자 또는 앱의 계정 ID입니다. 예들 들어 1234567 입니다. 행위자 사용자 이름과는 다릅니다. |
GITHUB_API_URL | API URL을 반환합니다. 예시: https://api.github.com |
GITHUB_BASE_REF | 워크플로 실행에서 끌어오기 요청의 기본 참조 또는 대상 분기의 이름입니다. 워크플로 실행을 트리거하는 이벤트가 pull_request 또는 pull_request_target 인 경우에만 설정됩니다. 예들 들어 main 입니다. |
GITHUB_ENV | 워크플로 명령에서 변수를 설정하는 파일에 대한 실행기 경로입니다. 이 파일의 경로는 현재 단계와 작업의 각 단계에 대한 변경 내용에 고유합니다. 예들 들어 /home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a 입니다. 자세한 내용은 "GitHub Actions에 대한 워크플로 명령" 항목을 참조하세요. |
GITHUB_EVENT_NAME | 워크플로를 트리거한 이벤트의 이름입니다. 예들 들어 workflow_dispatch 입니다. |
GITHUB_EVENT_PATH | 전체 이벤트 웹후크 페이로드가 포함된 실행기에서 파일의 경로입니다. 예들 들어 /github/workflow/event.json 입니다. |
GITHUB_GRAPHQL_URL | GraphQL API URL을 반환합니다. 예시: https://api.github.com/graphql |
GITHUB_HEAD_REF | 워크플로 실행에서 끌어오기 요청의 헤드 참조 또는 원본 분기입니다. 이 속성은 워크플로 실행을 트리거하는 이벤트가 pull_request 또는 pull_request_target 인 경우에만 설정됩니다. 예들 들어 feature-branch-1 입니다. |
GITHUB_JOB | 현재 작업의 job_id입니다. 예들 들어 greeting_job 입니다. |
GITHUB_OUTPUT | 워크플로 명령에서 현재 단계의 출력을 설정하는 파일에 대한 실행기 경로입니다. 이 파일의 경로는 현재 단계와 작업의 각 단계에 대한 변경 내용에 고유합니다. 예들 들어 /home/runner/work/_temp/_runner_file_commands/set_output_a50ef383-b063-46d9-9157-57953fc9f3f0 입니다. 자세한 내용은 "GitHub Actions에 대한 워크플로 명령" 항목을 참조하세요. |
GITHUB_PATH | 워크플로 명령에서 시스템 PATH 변수를 설정하는 파일에 대한 실행기 경로입니다. 이 파일의 경로는 현재 단계와 작업의 각 단계에 대한 변경 내용에 고유합니다. 예들 들어 /home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5 입니다. 자세한 내용은 "GitHub Actions에 대한 워크플로 명령" 항목을 참조하세요. |
GITHUB_REF | 워크플로 실행을 트리거한 분기 또는 태그의 완전한 형식 참조 입니다. push 에 의해 트리거된 워크플로의 경우 푸시된 분기 또는 태그 참조입니다. pull_request 에 의해 트리거된 워크플로의 경우 끌어오기 요청 병합 분기입니다. release 에 의해 트리거된 워크플로의 경우 생성된 릴리스 태그입니다. 다른 트리거의 경우 워크플로 실행을 트리거한 분기 또는 태그 참조입니다. 이벤트 유형에 대해 분기 또는 태그를 사용할 수 있는 경우에만 설정됩니다. 지정된 참조는 완전한 형식을 가집니다. 즉, 분기의 경우 refs/heads/<branch_name> , 끌어오기 요청의 경우 refs/pull/<pr_number>/merge , 태그의 경우 refs/tags/<tag_name> 형식을 따릅니다. 예들 들어 refs/heads/feature-branch-1 입니다. |
GITHUB_REF_NAME | 워크플로 실행을 트리거한 분기 또는 태그입니다. 해당 값은 GitHub에 표시된 분기 또는 태그 이름과 일치합니다. 예들 들어 feature-branch-1 입니다.끌어오기 요청의 경우 형식은 <pr_number>/merge 입니다. |
GITHUB_REF_PROTECTED | 분기 보호가 또는 규칙 집합이 워크플로 실행을 트리거한 ref에 대해 구성된 경우 true 입니다. |
GITHUB_REF_TYPE | 워크플로 실행을 트리거한 ref의 형식입니다. 유효한 값은 branch 또는 tag 입니다. |
GITHUB_REPOSITORY | 소유자 및 리포지토리 이름입니다. 예들 들어 octocat/Hello-World 입니다. |
GITHUB_REPOSITORY_ID | 리포지토리 ID. 예들 들어 123456789 입니다. 리포지토리 이름과는 다릅니다. |
GITHUB_REPOSITORY_OWNER | 리포지토리 소유자의 이름입니다. 예들 들어 octocat 입니다. |
GITHUB_REPOSITORY_OWNER_ID | 리포지토리 소유자 계정 ID. 예들 들어 1234567 입니다. 소유자의 이름과는 다른 값입니다. |
GITHUB_RETENTION_DAYS | 워크플로 실행 로그 및 아티팩트가 유지되는 일 수입니다. 예들 들어 90 입니다. |
GITHUB_RUN_ATTEMPT | 리포지토리 내 각 특정 워크플로 실행 시도의 고유한 번호입니다. 이 숫자는 워크플로의 실행의 첫 시도 시 1부터 시작하며 다시 실행할 때마다 증가합니다. 예들 들어 3 입니다. |
GITHUB_RUN_ID | 리포지토리 내에서 실행되는 각 워크플로의 고유한 숫자입니다. 워크플로 실행을 다시 실행하는 경우 이 숫자는 변경되지 않습니다.(예시: 1658821493 ). |
GITHUB_RUN_NUMBER | 리포지토리에 있는 특정 워크플로의 실행마다 고유한 숫자입니다. 이 숫자는 워크플로의 첫 실행 시 1부터 시작하며 새 실행마다 증가합니다. 워크플로 실행을 다시 실행하는 경우 이 숫자는 변경되지 않습니다.(예시: 3 ). |
GITHUB_SERVER_URL | GitHub Enterprise Cloud 서버의 URL입니다. 예시: https://github.com |
GITHUB_SHA | 워크플로를 트리거한 커밋 SHA입니다. 이 커밋 SHA의 값은 워크플로를 트리거한 이벤트에 따라 달라집니다. 자세한 내용은 "워크플로를 트리거하는 이벤트"을(를) 참조하세요. 예들 들어 ffac537e6cbbf934b08745a378932722df287a53 입니다. |
GITHUB_STEP_SUMMARY | 워크플로 명령의 작업 요약이 포함된 파일에 대한 실행기 경로입니다. 이 파일의 경로는 현재 단계와 작업의 각 단계에 대한 변경 내용에 고유합니다. 예들 들어 /home/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c 입니다. 자세한 내용은 "GitHub Actions에 대한 워크플로 명령" 항목을 참조하세요. |
GITHUB_TRIGGERING_ACTOR | 워크플로 실행을 시작한 사용자의 사용자 이름입니다. 워크플로 실행이 다시 실행인 경우 이 값은 github.actor 와 다를 수 있습니다. 다시 실행을 시작하는 행위자(github.triggering_actor )가 다른 권한을 갖고 있더라도 모든 워크플로 다시 실행은 github.actor 의 권한을 사용합니다. |
GITHUB_WORKFLOW | 워크플로의 이름입니다. 예들 들어 My test workflow 입니다. 워크플로 파일이 name 을 지정하지 않으면 이 변수의 값은 리포지토리에 있는 워크플로 파일의 전체 경로입니다. |
GITHUB_WORKFLOW_REF | 워크플로의 참조 경로입니다. 예들 들어 octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch 입니다. |
GITHUB_WORKFLOW_SHA | 워크플로 파일의 커밋 SHA입니다. |
GITHUB_WORKSPACE | 단계에 대한 실행기의 기본 작업 디렉터리 및 checkout 작업을 사용할 때 리포지토리의 기본 위치입니다. 예들 들어 /home/runner/work/my-repo-name/my-repo-name 입니다. |
RUNNER_ARCH | 작업을 실행하는 실행기의 아키텍처입니다. 가능한 값은 X86 , X64 , ARM , ARM64 입니다. |
RUNNER_DEBUG | 디버그 로깅을 사용하도록 설정한 경우에만 설정되며 항상 값이 1 입니다. 사용자 고유의 작업 단계에서 추가 디버깅 또는 자세한 로깅을 사용하도록 설정하는 지표로 유용할 수 있습니다. |
RUNNER_ENVIRONMENT | 작업을 실행하는 실행기의 환경입니다. 가능한 값은 GitHub에서 제공하는 GitHub 호스트형 실행기의 경우 github-hosted , 리포지토리 소유자가 구성한 자체 호스트형 실행기의 경우 self-hosted 입니다. |
RUNNER_NAME | 작업을 실행하는 실행기의 이름입니다. 실행기 이름은 리포지토리의 실행기로 워크플로 실행 시 고유하지 않을 수 있으며 조직 수준에서 동일한 이름을 사용할 수 있습니다.(예시: Hosted Agent ). |
RUNNER_OS | 작업을 실행하는 실행기의 운영 체제입니다. 가능한 값은 Linux , Windows , 또는 macOS 입니다.(예시: Windows ). |
RUNNER_TEMP | 실행기의 임시 디렉터리에 대한 경로입니다. 이 디렉터리는 각 작업의 시작과 끝에 비워집니다. 실행기 사용자 계정에 삭제 권한이 없는 경우 파일이 제거되지 않습니다.(예시: D:\a\_temp ). |
RUNNER_TOOL_CACHE | GitHub 호스팅 실행기에 대해 미리 설치된 도구가 포함된 디렉터리의 경로입니다. 자세한 내용은 "GitHub 호스팅 실행기 사용"을 참조하세요.(예시: C:\hostedtoolcache\windows ). |
참고: 작업 내에서 워크플로 실행의 URL을 사용해야 하는 경우 이러한 $GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID
변수를 결합할 수 있습니다.
운영 체제 검색
RUNNER_OS
기본 환경 변수 및 해당 컨텍스트 속성 ${{ runner.os }}
을(를) 사용하여 다른 운영 체제에 사용할 수 있는 단일 워크플로 파일을 작성할 수 있습니다. 예를 들어 실행기에서 사용하는 셸에 따라 다른 환경 변수의 구문을 변경하지 않고 운영 체제를 macos-latest
에서 windows-latest
로 변경하면 다음 워크플로를 성공적으로 실행할 수 있습니다.
on: workflow_dispatch jobs: if-Windows-else: runs-on: macos-latest steps: - name: condition 1 if: runner.os == 'Windows' run: echo "The operating system on the runner is $env:RUNNER_OS." - name: condition 2 if: runner.os != 'Windows' run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
on: workflow_dispatch
jobs:
if-Windows-else:
runs-on: macos-latest
steps:
- name: condition 1
if: runner.os == 'Windows'
run: echo "The operating system on the runner is $env:RUNNER_OS."
- name: condition 2
if: runner.os != 'Windows'
run: echo "The operating system on the runner is not Windows, it's $RUNNER_OS."
이 예시에서 두 if
문은 runner
컨텍스트의 os
속성을 확인하여 실행기의 운영 체제를 확인합니다. if
조건은 GitHub Actions에 의해 처리되며, 실행기로 전송되는 검사에서 true
로 확인되는 단계만 처리됩니다. 여기서는 검사 중 하나가 항상 true
이고 다른 하나가 false
이므로 단계 중 하나만 실행기에 전송됩니다. 작업이 실행기로 전송되면 단계가 실행되고 명령의 echo
의 환경 변수가 적절한 구문(Windows PowerShell의 경우 $env:NAME
, Linux와 macOS의 bash와 sh인 경우 $NAME
)을 사용하여 보간됩니다. 이 예시에서 문 runs-on: macos-latest
는 두 번째 단계가 실행될 것임을 의미합니다.
워크플로의 단계와 작업 간에 값 전달
작업의 한 단계에서 값을 생성하는 경우 기존 또는 새 환경 변수에 값을 할당한 다음 이를 GITHUB_ENV
환경 파일에 작성하여 동일한 작업의 후속 단계에서 값을 사용할 수 있습니다. 환경 파일은 작업에서 직접 사용하거나 run
키워드를 사용하여 워크플로 파일의 셸 명령에서 사용할 수 있습니다. 자세한 내용은 "GitHub Actions에 대한 워크플로 명령" 항목을 참조하세요.
워크플로의 한 작업 단계에서 워크플로의 다른 작업의 단계로 값을 전달하려는 경우 값을 작업 출력으로 정의할 수 있습니다. 그런 다음, 다른 작업의 단계에서 이 작업 출력을 참조할 수 있습니다. 자세한 내용은 "GitHub Actions에 대한 워크플로 구문" 항목을 참조하세요.