Skip to main content

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

워크플로 정보

트리거, 구문 및 고급 기능을 포함하여 GitHub Actions 워크플로에 대한 개략적인 개요를 알아봅니다.

워크플로 정보

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

워크플로는 리포지토리의 .github/workflows 디렉터리에 정의되며 리포지토리에는 여러 워크플로가 있을 수 있으며, 각 워크플로는 다른 작업 세트를 수행할 수 있습니다. 예를 들어 끌어오기 요청을 빌드 및 테스트하는 워크플로, 릴리스가 생성될 때마다 애플리케이션을 배포하는 워크플로, 누군가가 새 이슈를 열 때마다 레이블을 추가하는 워크플로가 있을 수 있습니다.

워크플로 기본 사항

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

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

이러한 기본 구성 요소에 대한 자세한 내용은 "GitHub Actions 이해"를 참조하세요.

워크플로 개요

워크플로 트리거

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

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

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

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

워크플로 구문

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

예제 워크로드 만들기

GitHub Actions는 YAML 구문을 사용하여 워크플로를 정의합니다. 각 워크플로는 코드 리포지토리의 .github/workflows 디렉터리에 별도의 YAML 파일로 저장됩니다.

리포지토리에서 코드가 푸시될 때마다 일련의 명령을 자동으로 트리거하는 예제 워크플로를 만들 수 있습니다. 이 워크플로에서 GitHub Actions는 푸시된 코드를 체크 아웃하고 bats 테스트 프레임워크를 설치하고, 기본 명령 bats -v를 실행하여 bats 버전을 출력합니다.

  1. 리포지토리에서 워크플로 파일을 저장할 .github/workflows/ 디렉터리를 만듭니다.

  2. .github/workflows/ 디렉터리에서 learn-github-actions.yml이라는 새 파일을 만들고 다음 코드를 추가합니다.

    YAML
    name: learn-github-actions
    on: [push]
    jobs:
      check-bats-version:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v2
          - uses: actions/setup-node@v2
            with:
              node-version: '14'
          - run: npm install -g bats
          - run: bats -v
  3. 변경 내용을 커밋하고 GitHub 리포지토리에 푸시합니다.

이제 새 GitHub Actions 워크플로 파일이 리포지토리에 설치되고, 누군가가 리포지토리에 변경 내용을 푸시할 때마다 자동으로 실행됩니다. 워크플로의 실행 기록에 관한 세부 정보를 보려면 “워크플로 실행에 대한 작업 보기”를 참조하세요.

워크플로 파일 이해

YAML 구문을 사용하여 워크플로 파일을 만드는 방법의 이해를 돕기 위해 이 섹션에서는 소개 예제의 각 줄에 대해 설명합니다.

name: learn-github-actions
선택적 - GitHub 리포지토리의 "작업" 탭에 표시되는 워크플로의 이름입니다.
on: [push]
이 워크플로의 트리거를 지정합니다. 이 예제에서는 push 이벤트를 사용하므로 누군가가 리포지토리에 변경 내용을 푸시하거나 끌어오기 요청을 병합할 때마다 워크플로 실행이 트리거됩니다. 모든 분기에 대한 푸시로 트리거됩니다. 특정 분기, 경로 또는 태그에 푸시할 때만 실행되는 구문의 예제는 “GitHub Actions의 워크플로 구문”을 참조하세요.
jobs:
learn-github-actions 워크플로에서 실행되는 모든 작업을 그룹화합니다.
check-bats-version:
check-bats-version이라는 작업을 정의합니다. 자식 키는 작업의 속성을 정의합니다.
  runs-on: ubuntu-latest
Ubuntu Linux 실행기의 최신 버전에서 실행되도록 작업을 구성합니다. 즉, GitHub에서 호스트된 새 가상 머신에서 작업이 실행됩니다. 다른 실행기를 사용하는 구문 예제는 “GitHub Actions의 워크플로 구문”을 참조하세요.
  steps:
check-bats-version 작업에서 실행되는 모든 단계를 그룹화합니다. 이 섹션 아래에 중첩된 각 항목은 별도의 작업 또는 셸 스크립트입니다.
    - uses: actions/checkout@v2
uses 키워드는 이 단계에서 actions/checkout 작업의 v3를 실행하도록 지정합니다. 이 작업은 리포지토리를 실행기로 체크 아웃하여 스크립트 또는 코드에 대한 기타 작업(예: 빌드 및 테스트 도구)을 실행할 수 있도록 합니다. 워크플로가 리포지토리의 코드에 대해 실행될 때마다 체크 아웃 작업을 사용해야 합니다.
    - uses: actions/setup-node@v2
      with:
        node-version: '14'
이 단계에서는 actions/setup-node@v2 작업을 사용하여 지정된 버전의 Node.js를 설치합니다(이 예제에서는 v14 사용). 이렇게 하면 nodenpm 명령이 모두 PATH에 배치됩니다.
    - run: npm install -g bats
run 키워드는 실행기에서 명령을 실행하도록 작업에 지시합니다. 이 예제에서는 npm을 사용하여 bats 소프트웨어 테스트 패키지를 설치합니다.
    - run: bats -v
최종적으로, 소프트웨어 버전을 출력하는 매개 변수와 함께 bats 명령을 실행합니다.

워크플로 파일 시각화

아래 다이어그램에서, 방금 만든 워크플로 파일 및 GitHub Actions 구성 요소가 계층 구조로 구성된 방식을 확인할 수 있습니다. 각 단계는 단일 작업 또는 셸 스크립트를 실행합니다. 1단계와 2단계는 작업을 실행하는 반면, 3단계와 4단계는 셸 스크립트를 실행합니다. 워크플로에 대해 미리 빌드된 작업을 더 찾으려면 “작업 찾기 및 사용자 지정”을 참조하세요.

워크플로 개요

워크플로 실행에 대한 작업 보기

워크플로가 트리거되면 워크플로를 실행하는 워크플로 실행이 만들어집니다. 워크플로 실행이 시작된 후 GitHub에서 실행 진행률 시각화 그래프를 확인하고 각 단계의 작업을 볼 수 있습니다.

  1. your GitHub Enterprise Server instance에서 리포지토리의 기본 페이지로 이동합니다.

  2. 리포지토리 이름 아래에 있는 작업을 클릭합니다.

    리포지토리로 이동

  3. 왼쪽 사이드바에서 확인할 워크플로를 클릭합니다.

    워크플로 결과 스크린샷

  4. “워크플로 실행”에서 확인할 실행의 이름을 클릭합니다.

    워크플로 실행 스크린샷

  5. 작업 또는 시각화 그래프에서 보려는 작업을 클릭합니다.

    작업 선택

  6. 각 단계의 결과를 봅니다.

    워크플로 실행 세부 정보 스크린샷

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

시작 워크플로 사용

GitHub은 사용자 고유의 연속 통합 워크플로를 만들기 위해 사용자 지정할 수 있는 미리 구성된 시작 워크플로를 제공합니다. GitHub Enterprise Server은(는) 코드를 분석하고 리포지토리에 유용할 수 있는 CI 시작 워크플로를 보여 줍니다. 예를 들어 리포지토리에 Node.js 코드가 포함된 경우 Node.js 프로젝트에 대한 제안이 표시됩니다. 시작 워크플로를 시작 위치로 사용하여 사용자 지정 워크플로를 빌드하거나 있는 그대로 사용할 수 있습니다.

actions/starter-workflows 리포지토리의 your GitHub Enterprise Server instance에서 시작 워크플로의 전체 목록을 찾아볼 수 있습니다.

시작 워크플로 사용 및 생성에 대한 자세한 내용은 "시작 워크플로 사용" 및 "조직에 대한 시작 워크플로 만들기"를 참조하세요.

고급 워크플로 기능

이 섹션에서는 더 복잡한 워크플로를 만드는 데 도움이 되는 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"

자세한 내용은 “암호화된 비밀”을 참조하세요.

종속 작업 만들기

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

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

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: [12, 14, 16]
    steps:
      - uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node }}

자세한 내용은 “작업에 매트릭스 사용”을 참조하세요.

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

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

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie
    services:
      postgres:
        image: postgres
    steps:
      - name: Check out repository code
        uses: actions/checkout@v2
      - 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 배열에 모든 레이블이 있는 실행기에서만 실행됩니다. 작업은 우선 지정된 레이블이 있는 유휴 자체 호스팅 실행기로 이동합니다.

자체 호스팅 실행기 레이블에 대한 자세한 내용은 "자체 호스팅 실행기가 있는 레이블 사용"을 참조하세요.

환경 사용

워크플로에서 작업 실행을 제어하도록 보호 규칙 및 비밀을 사용하여 환경을 구성할 수 있습니다. 워크플로의 각 작업은 단일 환경을 참조할 수 있습니다. 환경을 참조하는 작업이 실행기에 전송되기 전에 환경에 대해 구성된 모든 보호 규칙이 전달되어야 합니다. 자세한 내용은 “배포에 환경 사용”을 참조하세요.