워크플로 정보
워크플로는 하나 이상의 작업을 실행할 구성 가능한 자동화된 프로세스입니다. 워크플로는 리포지토리에 체크 인된 YAML 파일에서 정의되며, 리포지토리의 이벤트로 트리거될 때 실행되거나 수동으로 또는 정의된 일정에 따라 트리거될 수 있습니다.
워크플로는 리포지토리의 .github/workflows
디렉터리에 정의됩니다. 리포지토리에 다음과 같은 각각의 다른 작업 집합을 수행하는 여러 워크플로가 있을 수 있습니다.
- 끌어오기 요청을 빌드하고 테스트합니다.
- 릴리스가 생성될 때마다 애플리케이션을 배포합니다.
- 새 문제가 보고될 때마다 레이블을 추가합니다.
워크플로 기본 사항
워크플로에는 다음과 같은 기본 구성 요소가 포함되어야 합니다.
- 워크플로를 트리거하는 하나 이상의 이벤트.
- 하나 이상의 _작업_이며, 각 작업은 실행기 머신에서 실행되고 일련의 하나 이상의 _단계_를 실행합니다.
- 각 단계에서는 워크플로를 간소화할 수 있는 재사용 가능한 확장인 작업을 정의하거나 실행하는 스크립트를 실행할 수 있습니다.
이러한 기본 구성 요소를 사용하는 방법에 관한 자세한 내용은 "GitHub Actions 이해"을 참조하세요.
워크플로 트리거
워크플로 트리거는 워크플로를 실행하게 하는 이벤트입니다. 해당 이벤트는 다음과 같습니다.
- 워크플로의 리포지토리에서 발생하는 이벤트
- GitHub 외부에서 발생하고 GitHub에서
repository_dispatch
이벤트를 트리거하는 이벤트 - 예약된 시간
- 수동
예를 들어 리포지토리의 기본 분기로 푸시되거나, 릴리스가 생성되거나, 이슈가 열리면 실행되도록 워크플로를 구성할 수 있습니다.
자세한 내용은 "워크플로 트리거"을 참조하고 이벤트의 전체 목록은 "워크플로를 트리거하는 이벤트"을 참조하세요.
워크플로 구문
워크플로는 YAML을 사용하여 정의됩니다. 워크플로 작성에 대한 YAML 구문의 전체 참조는 "GitHub Actions에 대한 워크플로 구문"을 참조하세요.
워크플로 실행 다시 실행, 취소 또는 삭제와 같은 워크플로 실행 관리에 대한 자세한 내용은 "워크플로 실행 및 배포 관리"를 참조하세요.
워크플로 템플릿 사용
GitHub은(는) 미리 구성된 워크플로 템플릿을 제공하며, 이를 그대로 사용하거나 사용자 지정하여 자신만의 워크플로를 만들 수 있습니다. GitHub은(는) 코드를 분석하여 리포지토리에 유용할 수 있는 워크플로 템플릿을 보여줍니다. 예를 들어 리포지토리에 Node.js 코드가 포함된 경우 Node.js 프로젝트에 대한 제안이 표시됩니다.
이러한 워크플로 템플릿은 빠르게 시작하고 실행할 수 있도록 설계되어 다음과 같은 다양한 구성을 제공합니다.
- CI: 연속 통합 워크플로
- 배포: 배포 워크플로
- 자동화: 워크플로 자동화
- 코드 검사: 코드 검사 워크플로
- 페이지: 페이지 워크플로
워크플로 템플릿을 시작 위치로 사용하여 사용자 지정 워크플로를 빌드하거나 있는 그대로 사용할 수 있습니다. 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@v3
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 }}-
자세한 내용은 "워크플로 속도를 높이기 위한 종속성 캐싱"을(를) 참조하세요.
데이터베이스 및 서비스 컨테이너 사용
작업에 데이터베이스 또는 캐시 서비스가 필요한 경우 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 호스팅 실행기 레이블에 대한 자세한 내용은 “GitHub 호스팅 실행기 사용”를 참조하세요.
워크플로 다시 사용
다른 워크플로 내에서 한 워크플로를 호출하여 조직과 워크플로를 공개 또는 비공개적으로 공유할 수 있습니다. 이렇게 하면 워크플로를 다시 사용할 수 있으므로 중복을 방지하고 워크플로를 더 쉽게 유지 관리할 수 있습니다. 자세한 내용은 "워크플로 다시 사용"을(를) 참조하세요.
워크플로에 대한 보안 강화
GitHub는 워크플로의 보안을 강화하는 데 사용할 수 있는 보안 기능을 제공합니다. GitHub의 기본 제공 기능으로 이용하는 작업의 약점에 대한 알림을 받거나 워크플로의 작업을 최신 상태로 유지하는 프로세스를 자동화할 수 있습니다. 자세한 내용은 "GitHub의 보안 기능을 사용하여 안전하게 GitHub Actions 사용"을(를) 참조하세요.
환경 사용
워크플로에서 작업 실행을 제어하도록 보호 규칙 및 비밀을 사용하여 환경을 구성할 수 있습니다. 워크플로의 각 작업은 단일 환경을 참조할 수 있습니다. 환경을 참조하는 작업이 실행기에 전송되기 전에 환경에 대해 구성된 모든 보호 규칙이 전달되어야 합니다. 자세한 내용은 "배포 환경 관리" 항목을 참조하세요.