About workflows

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

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

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

Workflow basics

A workflow must contain the following basic components:

One or more events that will trigger the workflow.
One or more jobs, each of which will execute on a runner machine and run a series of one or more steps.
Each step can either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

For more information on these basic components, see GitHub Actions 이해.

Diagram of an event triggering Runner 1 to run Job 1, which triggers Runner 2 to run Job 2. Each of the jobs is broken into multiple steps.

Triggering a workflow

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

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

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

For more information, see 워크플로 트리거, and for a full list of events, see 워크플로를 트리거하는 이벤트.

Workflow syntax

Workflows are defined using YAML. For the full reference of the YAML syntax for authoring workflows, see GitHub Actions에 대한 워크플로 구문.

For more on managing workflow runs, such as re-running, cancelling, or deleting a workflow run, see 워크플로 실행 및 배포 관리.

Using workflow templates

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

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

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

Advanced workflow features

This section briefly describes some of the advanced features of GitHub Actions that help you create more complex workflows.

Storing secrets

If your workflows use sensitive data, such as passwords or certificates, you can save these in GitHub as secrets and then use them in your workflows as environment variables. This means that you will be able to create and share workflows without having to embed sensitive values directly in the workflow's YAML source.

This example job demonstrates how to reference an existing secret as an environment variable, and send it as a parameter to an example command.

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

For more information, see GitHub Actions에서 비밀 사용.

Creating dependent jobs

By default, the jobs in your workflow all run in parallel at the same time. If you have a job that must only run after another job has completed, you can use the needs keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the if conditional statement.

In this example, the setup, build, and test jobs run in series, with build and test being dependent on the successful completion of the job that precedes them:

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

For more information, see 워크플로에서 작업 사용.

Using a matrix

매트릭스 전략을 사용하면 단일 작업 정의에서 변수를 사용하여 변수의 조합을 기반으로 하는 여러 작업 실행을 자동으로 만들 수 있습니다. 예를 들어 매트릭스 전략을 사용하여 여러 버전의 언어 또는 여러 운영 체제에서 코드를 테스트할 수 있습니다. The matrix is created using the strategy keyword, which receives the build options as an array. For example, this matrix will run the job multiple times, using different versions of Node.js:

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

For more information, see 워크플로에서 작업 변형 실행.

Caching dependencies

If your jobs regularly reuse dependencies, you can consider caching these files to help improve performance. Once the cache is created, it is available to all workflows in the same repository.

This example demonstrates how to cache the ~/.npm directory:

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 }}-

For more information, see 워크플로 속도를 높이기 위한 종속성 캐싱.

Using databases and service containers

If your job requires a database or cache service, you can use the services keyword to create an ephemeral container to host the service; the resulting container is then available to all steps in that job and is removed when the job has completed. This example demonstrates how a job can use services to create a postgres container, and then use node to connect to the service.

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

For more information, see 컨테이너화된 서비스 사용.

Using labels to route workflows

If you want to be sure that a particular type of runner will process your job, you can use labels to control where jobs are executed. You can assign labels to a self-hosted runner in addition to their default label of self-hosted. Then, you can refer to these labels in your YAML workflow, ensuring that the job is routed in a predictable way. GitHub-hosted runners have predefined labels assigned.

This example shows how a workflow can use labels to specify the required runner:

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

A workflow will only run on a runner that has all the labels in the runs-on array. The job will preferentially go to an idle self-hosted runner with the specified labels.

To learn more about self-hosted runner labels, see 자체 호스트형 실행기로 레이블 사용.

Reusing workflows

한 워크플로를 호출하여 조직과 워크플로를 공개 또는 비공개적으로 공유할 수 있습니다. 이렇게 하면 워크플로를 다시 사용할 수 있으므로 중복을 방지하고 워크플로를 더 쉽게 유지 관리할 수 있습니다. 자세한 내용은 워크플로 다시 사용을(를) 참조하세요.

Security hardening for workflows

GitHub는 워크플로의 보안을 강화하는 데 사용할 수 있는 보안 기능을 제공합니다. GitHub의 기본 제공 기능으로 이용하는 작업의 약점에 대한 알림을 받거나 워크플로의 작업을 최신 상태로 유지하는 프로세스를 자동화할 수 있습니다. 자세한 내용은 GitHub의 보안 기능을 사용하여 안전하게 GitHub Actions 사용을(를) 참조하세요.

Using environments

You can configure environments with protection rules and secrets to control the execution of jobs in a workflow. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see 배포 환경 관리.

About workflows

이 문서의 내용