워크플로 정보

워크플로는 하나 이상의 작업을 실행할 구성 가능한 자동화된 프로세스입니다. 워크플로는 리포지토리에 체크 인된 YAML 파일에서 정의되며, 리포지토리의 이벤트로 트리거될 때 실행되거나 수동으로 또는 정의된 일정에 따라 트리거될 수 있습니다.

워크플로는 리포지토리의 .github/workflows 디렉터리에 정의됩니다. 리포지토리에 다음과 같은 각각의 다른 작업 집합을 수행하는 여러 워크플로가 있을 수 있습니다.

끌어오기 요청을 빌드하고 테스트합니다.
릴리스가 생성될 때마다 애플리케이션을 배포합니다.
새 문제가 보고될 때마다 레이블을 추가합니다.

워크플로 기본 사항

워크플로에는 다음과 같은 기본 구성 요소가 포함되어야 합니다.

워크플로를 트리거하는 하나 이상의 이벤트.
하나 이상의 _작업_이며, 각 작업은 실행기 머신에서 실행되고 일련의 하나 이상의 _단계_를 실행합니다.
각 단계에서는 워크플로를 간소화할 수 있는 재사용 가능한 확장인 작업을 정의하거나 실행하는 스크립트를 실행할 수 있습니다.

이러한 기본 구성 요소를 사용하는 방법에 관한 자세한 내용은 Understanding GitHub Actions을(를) 참조하세요.

Runner 1이 작업 1을 실행하도록 트리거하는 이벤트 다이어그램으로, Runner 2를 트리거하여 작업 2를 실행합니다. 각 작업은 여러 단계로 구분됩니다.

워크플로 트리거

워크플로 트리거는 워크플로를 실행하게 하는 이벤트입니다. 해당 이벤트는 다음과 같습니다.

워크플로의 리포지토리에서 발생하는 이벤트
GitHub 외부에서 발생하고 GitHub에서 repository_dispatch 이벤트를 트리거하는 이벤트
예약된 시간
설명서

예를 들어 리포지토리의 기본 분기로 푸시되거나, 릴리스가 생성되거나, 이슈가 열리면 실행되도록 워크플로를 구성할 수 있습니다.

자세한 내용은 워크플로 트리거을(를) 참조하고 이벤트의 전체 목록은 워크플로를 트리거하는 이벤트을(를) 참조하세요.

워크플로 구문

워크플로는 YAML을 사용하여 정의됩니다. 워크플로 작성에 대한 YAML 구문의 전체 참조는 GitHub Actions에 대한 워크플로 구문을(를) 참조하세요.

워크플로 실행 다시 실행, 취소 또는 삭제와 같은 워크플로 실행 관리에 대한 자세한 내용은 워크플로 실행 및 배포 관리을(를) 참조하세요.

워크플로 템플릿 사용

GitHub는 미리 구성된 워크플로 템플릿을 제공하며, 이를 그대로 사용하거나 사용자 지정하여 자신만의 워크플로를 만들 수 있습니다. GitHub는 코드를 분석하여 리포지토리에 유용할 수 있는 워크플로 템플릿을 보여줍니다. 예를 들어 리포지토리에 Node.js 코드가 포함된 경우 Node.js 프로젝트에 대한 제안이 표시됩니다.

이러한 워크플로 템플릿은 빠르게 시작하고 실행할 수 있도록 설계되어 다음과 같은 다양한 구성을 제공합니다.

워크플로 템플릿을 시작 위치로 사용하여 사용자 지정 워크플로를 빌드하거나 있는 그대로 사용할 수 있습니다. actions/starter-workflows 리포지토리에서 워크플로 템플릿의 전체 목록을 찾아볼 수 있습니다.

고급 워크플로 기능

이 섹션에서는 더 복잡한 워크플로를 만드는 데 도움이 되는 GitHub Actions의 고급 기능 중 일부를 간략하게 설명합니다.

비밀 저장

워크플로에서 암호 또는 인증서와 같은 중요한 데이터를 사용하는 경우 GitHub에 비밀로 저장한 다음 워크플로에서 환경 변수로 사용할 수 있습니다.__ 즉, 워크플로의 YAML 원본에 중요한 값을 직접 포함할 필요 없이 워크플로를 만들고 공유할 수 있습니다.

이 예시 작업은 기존 비밀을 환경 변수로 참조하고 예시 명령에 매개 변수로 보내는 방법을 보여 줍니다.

jobs:
  example-job:
    runs-on: ubuntu-latest
    steps:
      - name: Retrieve secret
        env:
          super_secret: ${{ secrets.SUPERSECRET }}
        run: |
          example-command "$super_secret"

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

종속 작업 만들기

기본적으로 워크플로의 작업은 모두 동시에 병렬로 실행됩니다. 다른 작업이 완료된 후에만 실행해야 하는 작업이 있는 경우 needs 키워드를 사용하여 이 종속성을 만들 수 있습니다. 작업 중 하나가 실패하면 모든 종속 작업은 건너뜁니다. 그러나 작업을 계속해야 하는 경우 if 조건문을 사용하여 이를 정의할 수 있습니다.

이 예시에서 setup, build 및 test 작업은 연달아 실행되며 build와 test는 그 앞 작업의 성공적인 완료에 따라 실행됩니다.

jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - run: ./setup_server.sh
  build:
    needs: setup
    runs-on: ubuntu-latest
    steps:
      - run: ./build_server.sh
  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: ./test_server.sh

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

매트릭스 사용

매트릭스 전략을 사용하면 단일 작업 정의에서 변수를 사용하여 변수의 조합을 기반으로 하는 여러 작업 실행을 자동으로 만들 수 있습니다. 예를 들어 매트릭스 전략을 사용하여 여러 버전의 언어 또는 여러 운영 체제에서 코드를 테스트할 수 있습니다. 매트릭스는 빌드 옵션을 배열로 수신하는 strategy 키워드를 사용하여 만들어집니다. 예를 들어 이 매트릭스는 여러 버전의 Node.js 사용하여 작업을 여러 번 실행합니다.

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [14, 16]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}

자세한 내용은 워크플로에서 작업 변형 실행을(를) 참조하세요.

종속성 캐싱

작업에서 종속성을 정기적으로 다시 사용하는 경우 이러한 파일을 캐싱하여 성능을 개선하는 것이 좋습니다. 캐시가 만들어지면 동일한 리포지토리의 모든 워크플로에서 사용할 수 있습니다.

이 예시에서는 ~/.npm 디렉터리를 캐싱하는 방법을 보여 줍니다.

jobs:
  example-job:
    steps:
      - name: Cache node modules
        uses: actions/cache@v4
        env:
          cache-name: cache-node-modules
        with:
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-

자세한 내용은 Dependency caching reference을(를) 참조하세요.

데이터베이스 및 서비스 컨테이너 사용

작업에 데이터베이스 또는 캐시 서비스가 필요한 경우 services 키워드를 사용하여 서비스를 호스팅하는 임시 컨테이너를 만들 수 있습니다. 그러면 해당 작업의 모든 단계에서 결과 컨테이너를 사용할 수 있으며 작업이 완료되면 제거됩니다. 이 예시에서는 작업이 services을 사용하여 postgres 컨테이너를 만든 다음 서비스에 연결하는 데 node을 사용할 수 있는 방법을 보여 줍니다.

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:20-bookworm-slim
    services:
      postgres:
        image: postgres
    steps:
      - name: Check out repository code
        uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Connect to PostgreSQL
        run: node client.js
        env:
          POSTGRES_HOST: postgres
          POSTGRES_PORT: 5432

자세한 내용은 컨테이너화된 서비스 사용을(를) 참조하세요.

레이블을 사용하여 워크플로 라우팅

특정 유형의 실행기에서 작업을 처리하도록 하려면 레이블을 사용하여 작업이 실행되는 위치를 제어할 수 있습니다. 자체 호스팅 실행기에서 self-hosted의 기본 레이블 외에도 레이블을 할당할 수 있습니다. 그런 다음, YAML 워크플로에서 이러한 레이블을 참조하여 작업이 예측 가능한 방식으로 라우팅되도록 할 수 있습니다. GitHub 호스트형 실행기에는 미리 정의된 레이블이 할당됩니다.

이 예시에서는 다음과 같이 워크플로에서 레이블을 사용하여 필요한 실행기를 지정하는 방법을 보여 줍니다.

jobs:
  example-job:
    runs-on: [self-hosted, linux, x64, gpu]

워크플로는 runs-on 배열에 모든 레이블이 있는 실행기에서만 실행됩니다. 작업은 우선 지정된 레이블이 있는 유휴 자체 호스팅 실행기로 이동합니다. 사용할 수 없는 경우 지정된 레이블이 있는 GitHub 호스팅 실행기가 있으면 작업이 GitHub 호스팅 실행기로 이동합니다.

자체 호스팅 실행기 레이블에 대한 자세한 내용은 자체 호스트형 실행기로 레이블 사용을(를) 참조하세요.

GitHub 호스팅 실행기 레이블에 대한 자세한 내용은 About GitHub-hosted runners을(를) 참조하세요.

워크플로 정보

이 문서의 내용