환경 변수 및 아티팩트 데이터를 사용하여 워크플로 사용자 지정

12분

이제 기본 및 사용자 지정 환경 변수, 사용자 지정 스크립트, 캐시 종속성, 작업 간 아티팩트 데이터를 전달하는 방법에 대해 알아봅니다. 또한 GitHub 웹 사이트와 REST API 엔드포인트에서 워크플로 로그에 액세스하는 방법에 대해서도 알아보겠습니다.

기본 환경 변수 및 컨텍스트

GitHub Actions 워크플로에는 작업을 실행하는 실행기 내에서만 사용할 수 있는 몇 가지 기본 환경 변수가 있습니다. 이러한 기본 변수는 대/소문자를 구분하며 시스템 및 현재 사용자의 구성 값을 참조하세요. 이러한 기본 환경 변수를 사용하여 하드 코드된 파일 경로를 사용하는 대신 파일 시스템을 참조하는 것이 좋습니다. 기본 환경 변수를 사용하려면 $ 다음에 환경 변수 이름을 지정합니다.

jobs:
  prod-check:
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

기본 환경 변수 이외에 정의된 변수를 컨텍스트로 사용할 수 있습니다. 컨텍스트와 기본 변수는 둘 다 환경 정보에 대한 액세스를 제공한다는 점에서 유사하지만 몇 가지 중요한 차이점이 있습니다. 기본 환경 변수는 실행기 내에서만 사용할 수 있지만 컨텍스트 변수는 워크플로 내의 모든 지점에서 사용할 수 있습니다. 예를 들어 컨텍스트 변수를 사용하면 실행기가 실행되기 전에 if 문을 실행하여 식을 평가할 수 있습니다.

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploying to production server on branch $GITHUB_REF"

이 예에서는 github.ref 컨텍스트를 사용하여 워크플로를 트리거한 분기를 확인합니다. 분기가 main이면 실행자가 실행되고 “분기 $GITHUB_REF의 프로덕션 서버에 배포”를 출력합니다. 기본 환경 변수 $GITHUB_REF는 분기를 참조하는 실행기에서 사용됩니다. 기본 환경 변수는 모두 대문자이고 컨텍스트 변수는 모두 소문자입니다.

사용자 지정 환경 변수

기본 환경 변수 사용과 마찬가지로 워크플로 파일에서 사용자 정의 환경 변수를 사용할 수 있습니다. 사용자 지정 변수를 만들려면 env 컨텍스트를 사용하여 사용자 지정 변수를 워크플로 파일에 정의해야 합니다. 실행기 내의 환경 변수 값을 사용하려면 실행기 운영 체제의 일반 메서드를 사용하여 환경 변수를 읽을 수 있습니다.

name: CI
on: push
jobs:
  prod-check:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - run: echo "Nice work, $First_Name. Deploying to production server on branch $GITHUB_REF"
        env:
          First_Name: Mona

워크플로의 스크립트

앞의 워크플로 코드 조각 예에서 run 키워드는 단순히 텍스트 문자열을 출력하는 데 사용됩니다. run 키워드는 작업에 대해 실행기에서 명령을 실행하도록 지시하므로 run 키워드를 사용하여 작업 또는 스크립트를 실행합니다.

jobs:
  example-job:
    steps:
      - run: npm install -g bats

이 예에서는 run 키워드를 사용하여 bats 소프트웨어 테스트 패키지를 설치하기 위해 npm을 사용합니다. 스크립트를 작업으로 실행할 수도 있습니다. 일반적으로 .github/scripts/ 디렉터리에서 수행되는 리포지토리에 스크립트를 저장한 다음 run 키워드를 사용하여 경로 및 셸 형식을 제공할 수 있습니다.

jobs:
  example-job:
    steps:
      - name: Run build script
        run: ./.github/scripts/build.sh
        shell: bash

캐시 작업에 대한 캐시 종속성

워크플로를 빌드할 때 동일한 출력을 다시 사용하거나 한 실행에서 다른 실행으로 종속성을 다운로드해야 하는 경우가 종종 있습니다. 이러한 종속성을 반복적으로 다운로드하는 대신 워크플로를 더 빠르고 효율적으로 실행할 수 있도록 캐시할 수 있습니다. 이렇게 하면 GitHub 호스트된 실행기의 작업이 매번 정리된 가상 환경에서 시작되므로 워크플로에서 특정 단계를 실행하는 데 걸리는 시간을 크게 줄일 수 있습니다. 종속성 캐싱은 이러한 종속성 파일을 다시 만드는 데 걸리는 시간을 단축하는 데 도움이 됩니다.

작업에 대한 종속성을 캐시하려면 GitHub의 cache 작업을 사용합니다. 이 작업은 사용자가 제공한 고유 키로 식별된 캐시를 검색합니다. 작업이 캐시를 찾으면 구성한 경로로 캐시된 파일을 검색합니다. cache 작업을 사용하려면 몇 가지 특정 매개 변수를 설정해야 합니다.

매개 변수	설명	필수
키	캐시를 저장하고 검색할 때 만들어지는 키 식별자를 참조합니다.	예
경로	캐시하거나 검색할 실행기의 파일 경로를 참조합니다.	예
Restore-keys	원하는 캐시 키를 찾을 수 없는 경우 캐시에 대한 대체 기존 키로 구성됩니다.	No

steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

앞의 예에서 path는 ~/.npm으로 설정되고 key에는 실행기의 운영 체제와 package-lock.json 파일의 SHA-256 해시가 포함됩니다. 키 앞에 ID(이 예에서는 npm-cache)를 추가하면 restore-keys 대체를 사용하고 캐시가 여러 개 있는 경우 유용합니다.

작업 간 아티팩트 데이터 전달

워크플로 내의 종속성을 캐싱하는 것과 마찬가지로 동일한 워크플로 내에서 작업 간에 데이터를 전달할 수 있습니다. upload-artifact 및 download-artifact 동작을 사용하여 이 작업을 수행할 수 있습니다. 이전 작업의 아티팩트에 종속된 작업은 이전 작업이 성공적으로 완료될 때까지 기다려야 실행할 수 있습니다. 이 기능은 이전 작업에서 업로드한 아티팩트를 기반으로 순차적으로 실행해야 하는 일련의 작업이 있는 경우에 유용합니다. 예를 들어 job_2는 needs: job_1 구문을 사용하여 job_1이 필요합니다.

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

이전 예제에는 2개의 작업이 있습니다. job_1은 file.txt 파일에 일부 텍스트를 쓴 다음 actions/upload-artifact@v2 작업을 사용하여 이 아티팩트를 업로드하고 나중에 워크플로에서 사용할 수 있도록 데이터를 저장합니다. job_2는 needs: job_1 구문을 사용하여 job_1을 완료하고 actions/download-artifact@v2 작업을 사용하여 해당 아티팩트를 다운로드한 다음 file.txt의 콘텐츠를 출력해야 합니다.

워크플로에서 단계 디버그 로깅 사용

경우에 따라 기본 워크플로 로그에서 특정 워크플로 실행, 작업 또는 단계가 실패한 이유를 진단하기에 충분한 세부 정보를 제공하지 못합니다. 이 경우 실행 및 단계라는 두 가지 옵션에 대해 추가 디버그 로깅을 사용하도록 설정할 수 있습니다. 리포지토리에 대한 admin 액세스가 필요한 두 개의 리포지토리 비밀을 true로 설정하여 이 진단 로깅을 사용하도록 설정합니다.

실행기 진단 로깅을 사용하도록 설정하려면 워크플로를 포함하는 리포지토리의 ACTIONS_RUNNER_DEBUG 비밀을 true로 설정합니다.
단계 진단 로깅을 사용하도록 설정하려면 워크플로를 포함하는 리포지토리의 ACTIONS_STEP_DEBUG 비밀을 true로 설정합니다.

사용자 인터페이스에서 워크플로 로그 액세스

성공적인 자동화에 대해 생각할 때, 자동화된 것을 확인하는 데 최소한의 시간을 소비하여 관련된 항목에 집중할 수 있는 것을 목표로 합니다. 하지만 경우에 따라 일이 계획대로 되지 않을 때도 있고 무슨 일이 일어났는지 검토해야 할 수도 있습니다. 디버깅 프로세스는 매우 번거로울 수 있지만 GitHub는 현재 디버깅 단계의 컨텍스트를 유지하면서 작업 간에 빠르게 이동할 수 있는 명확한 레이아웃 구조를 제공합니다. GitHub에서 실행되는 워크플로의 로그를 보려면 다음 단계를 수행합니다.

리포지토리의 작업 탭으로 이동합니다.
왼쪽 사이드바에서 원하는 워크플로를 클릭합니다.
워크플로 실행 목록에서 원하는 실행을 선택합니다.
작업 아래에서 원하는 작업을 선택합니다.
로그 출력을 읽습니다.

워크플로 내에 여러 번의 실행이 있는 경우 워크플로를 선택한 후 상태 필터를 선택하고 실패로 설정하여 해당 워크플로 내에서 실패한 실행만 표시할 수도 있습니다.

REST API에서 워크플로 로그 액세스

GitHub를 사용하여 로그를 보는 것 이외에도 GitHub의 REST API를 사용하여 워크플로 실행에 대한 로그를 보거나 워크플로를 다시 실행하고 또는 워크플로 실행을 취소할 수도 있습니다. API를 사용하여 워크플로 실행의 로그를 보려면 로그 엔드포인트에 GET 요청을 보내야 합니다. 리포지토리에 대한 읽기 권한이 있는 모든 사용자는 이 엔드포인트를 사용할 수 있습니다. 리포지토리가 프라이빗인 경우 repo 범위가 있는 액세스 토큰을 사용해야 합니다.

예를 들어 특정 워크플로 실행 로그를 보기 위한 GET 요청은 다음 경로를 따릅니다.

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

계속