Apidog

올인원 협업 API 개발 플랫폼

API 설계

API 문서

API 디버깅

API 모킹

API 자동화 테스트

무료 회원가입
다운로드Mac 또는 Linux용
Home

/

로컬에서 Act로 GitHub Actions 실행하는 방법

로컬에서 Act로 GitHub Actions 실행하는 방법

Young-jae

Young-jae

Updated on April 16, 2025

GitHub Actions는 개발자들이 자신의 리포지토리 내에서 워크플로우를 자동화하는 방식을 혁신했습니다. 지속적인 통합 및 지속적인 배포(CI/CD) 파이프라인부터 이슈 레이블 자동화 및 릴리스 노트 생성을 위한 자동화까지, Actions는 GitHub 내에서 소프트웨어 개발 생명주기를 직접 관리할 수 있는 강력하고 통합된 방법을 제공합니다.

그러나 이러한 워크플로우를 개발하고 테스트하는 것은 때때로 번거롭게 느껴질 수 있습니다. 전통적인 사이클은 다음과 같습니다:

  1. 워크플로우 파일을 변경합니다(일반적으로 .github/workflows/에 위치함).
  2. 이 변경 사항을 커밋합니다.
  3. 이를 GitHub 리포지토리에 푸시합니다.
  4. GitHub의 러너가 작업을 가져와 실행할 때까지 기다립니다.
  5. 변경 사항이 작동했는지 또는 오류를 발생시켰는지 확인하기 위해 GitHub 웹사이트에서 로그를 분석합니다.

이 과정, 특히 기다리는 부분과 로컬 편집기와 GitHub UI 간의 컨텍스트 전환은 개발 속도를 상당히 저하시킬 수 있습니다. 특히 복잡한 워크플로우를 반복하거나 까다로운 이슈를 디버깅할 때 더욱 그렇습니다. Actions를 푸시하기 전에 테스트할 수 있다고 가정해 보십시오.

바로 이 지점에서 act가 등장합니다. 태그라인이 나타내듯이, "전 세계적으로 생각하고, act 지역적으로 행동하십시오". act는 Docker 컨테이너를 사용하여 로컬에서 GitHub Actions 워크플로우를 실행하도록 설계된 오픈 소스 명령줄 도구입니다. GitHub Actions에서 제공하는 환경을 시뮬레이션하여, 매번 작은 변경 사항을 커밋하고 푸시할 필요 없이 워크플로우를 빠르게 테스트하고 반복할 수 있습니다.

💡
멋진 API 테스트 도구가 필요하신가요? 아름다운 API 문서를 생성하는 데 도움이 됩니다.

개발 팀을 위한 통합된 올인원 플랫폼이 필요하신가요? 최대 생산성으로 함께 작업할 수 있도록 도와드립니다.

Apidog는 모든 요구 사항을 충족하며, Postman을 훨씬 더 저렴한 가격에 대체합니다!
버튼

왜 act로 GitHub Actions를 로컬에서 실행해야 할까요?

act를 개발 워크플로우에 통합하는 것의 이점은 상당합니다:

  1. 빠른 피드백: 이것이 가장 큰 장점입니다. 커밋-푸시-대기-디버그 사이클 대신, 로컬에서 변경한 직후 워크플로우를 즉시 실행할 수 있습니다. 몇 초 또는 몇 분 이내에 피드백을 받을 수 있으며, 몇 분 또는 수십 분 기다릴 필요가 없습니다. 이는 .github/workflows/ 파일의 개발 및 디버깅 프로세스를 대폭 가속화합니다.
  2. 로컬 작업 러너: 많은 프로젝트가 make, npm scripts 또는 사용자 정의 쉘 스크립트와 같은 도구를 사용하여 일반적인 개발 작업(빌드, 테스트, 린트 등)을 정의합니다. act를 사용하면 이러한 작업을 통합할 수 있습니다. 빌드, 테스트 및 기타 프로세스를 GitHub Actions 작업으로 정의한 다음, act를 사용하여 개발 목적으로 동일한 작업을 로컬에서 실행할 수 있습니다. 이를 통해 중복을 줄이고 로컬 개발 환경과 CI/CD 파이프라인 간의 일관성을 보장합니다. 작업을 한 번 정의하면 모든 곳에서 동일하게 실행됩니다.
  3. 오프라인 개발: 지속적인 인터넷 연결 없이도 기본 워크플로우 구문과 논리를 테스트할 수 있습니다(단, 초기 이미지 다운로드 및 특정 작업은 연결이 필요할 수 있습니다).
  4. 비용 절감: GitHub는 공용 리포지토리에 대해 관대한 무료 계층과 개인 리포지토리에 대한 합리적인 가격을 제공합니다. 그러나 복잡하거나 긴 워크플로우를 개발 중에 반복 실행하면 러너 시간이 소모될 수 있습니다. 로컬 테스트를 통해 이러한 사용을 피할 수 있습니다.
  5. 디버깅 힘: GitHub에서 실패한 Actions를 디버깅할 때는 추가 로깅을 추가하고 푸시 및 대기하는 것이 일반적입니다. act를 사용하면 로컬 환경을 검사하고, 볼륨을 마운트하며, Docker 컨테이너 내에서 더 발전된 디버깅 기술을 사용할 수 있습니다.

act는 어떻게 작동하나요?

act의 메커니즘을 이해하면 효과적으로 사용하는 데 도움이 되고 잠재적인 문제를 해결할 수 있습니다. 다음은 작동 방식에 대한 개요입니다:

  1. 워크플로우 파싱: 리포지토리의 루트 디렉토리에서 act 명령을 실행하면 .github/workflows/ 디렉토리에서 워크플로우 YAML 파일을 스캔합니다.
  2. 이벤트 트리거 시뮬레이션: 기본적으로 act는 push 이벤트를 시뮬레이션하지만, pull_request, workflow_dispatch 등의 다른 이벤트를 지정할 수 있습니다. 지정된 이벤트와 워크플로우 파일에 정의된 on: 트리거를 기반으로 어떤 워크플로우 및 작업이 실행되어야 하는지를 결정합니다.
  3. 종속성 분석: act는 워크플로우 내의 작업 간의 종속성을 분석하여 올바른 실행 순서를 결정합니다(needs: 키워드 사용).
  4. Docker 이미지 관리: 각 작업에 대해 act는 지정된 러너 환경을 식별합니다(예: runs-on: ubuntu-latest). 그런 다음 이를 특정 Docker 이미지에 매핑합니다. act는 Docker API를 사용하여:
  • 이미지 가져오기: 필요한 러너 이미지를 다운로드하고 컨테이너 작업에서 사용되는 Docker 이미지를 가져옵니다(uses: docker://...). 기본적으로 매번 실행 시 이미지를 가져옵니다.
  • 필요시 이미지 빌드: 작업이 로컬 Dockerfile을 가리키는 경우(uses: ./path/to/action), act는 로컬에서 Docker 이미지를 빌드할 수 있습니다.
  1. 컨테이너 실행: act는 Docker API를 사용하여 작업 내의 각 단계에 대한 컨테이너를 생성하고 실행합니다. 이러한 컨테이너는 GitHub Actions 환경을 최대한 가깝게 모방하도록 구성됩니다:
  • 환경 변수: 표준 GitHub Actions 환경 변수(GITHUB_SHA, GITHUB_REF, GITHUB_REPOSITORY, CI 등)가 주입됩니다.
  • 파일 시스템: 리포지토리 코드는 컨테이너의 작업 공간 디렉토리(/github/workspace)에 마운트됩니다. 단계에서 생성된 파일은 후속 단계에서 사용할 수 있도록 컨테이너 내에 유지됩니다.
  • 네트워킹: 컨테이너는 일반적으로 Docker 브리지 네트워크에서 실행되어 필요한 경우 통신할 수 있습니다(단, 네트워킹 세부사항은 GitHub 환경과 다를 수 있습니다).
  1. 로그 스트리밍: act는 실행 중인 컨테이너의 로그를 직접 터미널로 스트리밍하여 실행 진행 상황 및 오류에 대한 실시간 피드백을 제공합니다.

본질적으로, act는 로컬 Docker 컨테이너를 조율하여 GitHub Actions 워크플로우의 실행 흐름과 환경을 복제합니다.

전제 조건: Docker 설치

act의 핵심 의존성은 Docker입니다. act는 워크플로우 단계를 실행하는 데 필요한 격리된 환경을 생성하기 위해 Docker 엔진을 활용합니다. act를 설치하기 전에 시스템에 작동하는 Docker 설치가 있어야 합니다.

  • Docker 설치: 운영 체제에 대한 공식 지침을 따르십시오:
  • macOS: Docker Desktop for Mac
  • Windows: Docker Desktop for Windows (WSL 2 또는 Hyper-V 필요)
  • Linux: 배포에 대한 특정 지침을 따르십시오(예: Ubuntu, Fedora, Debian 등). Docker 명령을 sudo 없이 실행할 수 있도록 사용자 계정을 docker 그룹에 추가해야 합니다.
  • Docker 확인: 설치 후 터미널을 열고 docker run hello-world를 실행합니다. 이 명령은 작은 테스트 이미지를 다운로드하고 이를 컨테이너에서 실행합니다. 성공적으로 실행되면 Docker 설정이 준비되었습니다.

설치 act

Docker가 실행되면 act를 설치할 수 있습니다. 운영 체제 및 선호도에 따라 여러 가지 방법이 있습니다.

1. Homebrew (macOS 및 Linux)

Homebrew 패키지 관리자를 사용하는 경우 설치가 간단합니다:

brew install act

이것은 최신 안정 릴리스를 설치합니다. 절대적인 최신 개발 버전을 원하면(컴파일러가 필요할 수 있음) 다음을 사용할 수 있습니다:

brew install act --HEAD

2. GitHub CLI 확장 (macOS, Windows, Linux)

이미 GitHub CLI(gh)를 사용하는 경우 act를 확장으로 설치할 수 있습니다:

gh extension install nektos/gh-act

설치 후, gh 명령을 통해 act를 호출합니다:

gh act          # 단순히 'act' 대신
gh act -l
gh act pull_request

3. Chocolatey (Windows)

Windows에서 Chocolatey 패키지 관리자를 사용하는 경우:

choco install act-cli

(참고: 일부 소스에서는 act 대신 act-cli를 나열할 수 있습니다. 문제가 발생하면 Chocolatey 커뮤니티 리포지토리에서 최신 패키지 이름을 확인하세요.)

4. Scoop (Windows)

Windows에서 Scoop 패키지 관리자를 사용하는 경우:

scoop install act

5. WinGet (Windows)

Windows 패키지 관리자(winget)를 사용하는 경우:

winget install nektos.act

6. Linux 스크립트 설치자

패키지 관리자에 쉽게 접근할 수 없는 Linux 배포용 편리한 스크립트가 제공됩니다:

curl -s https://raw.githubusercontent.com/nektos/act/master/install.sh | sudo bash

(참고: 스크립트를 직접 sudo로 파이프할 때는 항상 주의해야 합니다. 보안 우려가 있는 경우 먼저 스크립트 내용을 검토하세요.)

7. 기타 방법 (Arch, COPR, MacPorts, Nix)

기타 패키지 관리자(예: pacman (Arch), COPR (Fedora), MacPorts, Nix)에 대한 설치 지침은 공식 act 문서에서 확인할 수 있습니다.

검증:

설치 후 새 터미널 창을 열고 다음을 실행합니다:

act --version
# 또는 gh 확장을 사용하는 경우:
gh act --version

이 명령은 설치된 act 버전을 출력하여 설치가 성공적으로 완료되었음을 확인합니다.

초기 구성: 러너 이미지

프로젝트 디렉토리에서 act를 처음 실행할 때 기본 러너 이미지 크기를 선택하라는 메시지가 표시될 수 있습니다. GitHub Actions는 다양한 리소스와 사전 설치된 소프트웨어를 가진 러너를 제공합니다. act는 이를 다른 기본 Docker 이미지를 사용하여 모방하려고 합니다.

일반적으로 다음과 같은 선택 옵션이 표시됩니다:

? 사용할 기본 이미지를 선택해 주세요:

  - Micro: nodejs 지원 최소 이미지 (~200MB) docker.io/node:16-buster-slim
  - Medium: 기본 도구가 포함된 Act 이미지 (~500MB) ghcr.io/catthehacker/ubuntu:act-latest
  - Large: GitHub Actions 러너 이미지 (~17GB) ghcr.io/catthehacker/ubuntu:full-latest

기본 이미지? [Medium]:
  • Micro: 공식 Node.js 슬림 이미지(예: node:16-buster-slim 또는 node:16-bullseye-slim)를 기반으로 합니다. 매우 작고 빠르게 다운로드되지만 Node.js 및 최소 시스템 라이브러리만 포함되어 있습니다. 만약 작업이 Node.js만 필요하든지, 모든 종속성을 스스로 설치하는 경우 적합합니다.
  • Medium: 사용자 catthehacker가 제공(예: catthehacker/ubuntu:act-latest, catthehacker/ubuntu:act-22.04). 이러한 이미지는 GitHub 러너에서 발견되는 보다 일반적인 도구를 포함하지만 여전히 상대적으로 경량입니다(약 500MB). 기능과 크기의 균형을 이룬 기본값으로 자주 권장됩니다.
  • Large: 또한 catthehacker에서 제공(예: catthehacker/ubuntu:full-latest, catthehacker/ubuntu:full-22.04). 이는 실제 GitHub 호스팅 러너의 파일 시스템 덤프에서 생성되며 거의 모든 사전 설치된 소프트웨어를 포함합니다. 최고의 호환성을 제공하지만 매우 크며(대개 17GB 초과), 초기 다운로드 시간이 길고 상당한 디스크 공간을 소모하게 됩니다.

추천: Medium 이미지를 사용하여 시작합니다. 이는 괜찮은 균형을 제공하며 많은 일반적인 사용 사례에 적합합니다. 소프트웨어를 누락으로 인해 문제가 발생하면 해당 작업에서 소프트웨어를 설치하거나 특정 러너에 대해 Large 이미지를 사용하는 것으로 전환할 수 있습니다(자세한 내용은 후술합니다).

act는 선택한 내용을 구성 파일(~/.actrc)에 저장합니다. 나중에 이 파일을 편집하거나 구성해야 하는 디렉토리에서 act를 다시 실행하여 기본값을 변경할 수 있습니다.

핵심 act 사용법: 워크플로우 실행하기

설치 및 구성 후 act 사용은 상대적으로 간단합니다. 터미널에서 프로젝트의 루트 디렉토리(.github 폴더가 포함된 디렉토리)로 이동하십시오.

1. 기본 이벤트(push) 실행

가장 간단한 명령은 기본 push 이벤트에 의해 트리거된 워크플로우를 실행합니다:

act
# 또는
gh act

act는 워크플로우를 파싱하고 on: push에 의해 트리거된 작업을 식별하며 필요한 Docker 이미지를 가져오고(이미 캐시되지 않은 경우) 작업을 실행합니다.

2. 사용 가능한 워크플로우 및 작업 목록

어떤 워크플로우와 작업이 act가 인식하고 기본 이벤트에 대해 실행할 것인지 확인하려면:

act -l
# 또는
gh act -l

이는 다음과 같은 목록을 출력합니다:

Stage  Job ID        Job name      Workflow name  Workflow file  Events
0      build         Build         CI Pipeline    ci.yaml        push
1      test          Test          CI Pipeline    ci.yaml        push
1      lint          Lint          Code Quality   codeql.yaml    push,pull_request

3. 특정 작업 실행

워크플로우에서 단일 작업만 테스트하려면 -j 플래그와 함께 작업 ID(act -l 출력에서) 사용:

act -j build
# 또는
gh act -j build

4. 특정 이벤트 트리거

워크플로우는 종종 push 외의 이벤트를 트리거합니다. act에 인수로 이벤트 이름을 제공하여 이러한 이벤트를 시뮬레이션할 수 있습니다:

# 풀 리퀘스트 이벤트 시뮬레이션
act pull_request

# workflow_dispatch 이벤트 시뮬레이션(수동 트리거)
act workflow_dispatch

# 스케줄 이벤트 시뮬레이션
act schedule

# 릴리스 이벤트 시뮬레이션
act release -e event.json # 필요시 이벤트 페이로드 세부정보 제공

act는 on:으로 지정된 이벤트에서 실행되도록 구성된 워크플로우 및 작업만 실행합니다.

5. workflow_dispatch를 위한 입력 전달

workflow_dispatch로 트리거된 워크플로우는 입력을 받을 수 있습니다. --input 플래그 또는 -i를 사용하여 이를 제공할 수 있습니다:

# 워크플로우에 'environment'라는 입력이 있다고 가정
act workflow_dispatch --input environment=staging

6. 비밀 처리

GitHub Actions 워크플로우는 종종 비밀(예: API 키 또는 토큰)을 필요로 합니다. act는 자신의 GitHub 비밀에 자동으로 접근하지 않습니다. 로컬에서 제공해야 합니다.

  • 대화식 프롬프트: -s 플래그를 사용합니다. act가 워크플로우에 정의된 각 비밀의 값을 입력하라는 메시지를 표시합니다:
act -s MY_SECRET_TOKEN -s ANOTHER_SECRET

대신, act -s만 사용하면 모든 비밀에 대해 프롬프트가 표시됩니다.

  • 환경 변수: 비밀은 종종 SECRET_로 접두어가 붙은 환경 변수로 전달됩니다. act를 실행하기 전에 셸에서 이를 정의할 수 있습니다:
export SECRET_MY_SECRET_TOKEN="your_value"
act
  • 비밀 파일: KEY=VALUE 쌍으로 파일(.secrets)을 생성합니다:
MY_SECRET_TOKEN=your_value
ANOTHER_SECRET=another_value

그런 다음 --secret-file 플래그와 함께 act를 실행합니다:

act --secret-file .secrets

(이 파일을 .gitignore에 추가하여 비밀을 커밋하지 않도록 하세요!)

7. 변수 및 환경 변수를 처리하기

  • 워크플로우 변수: 워크플로우 수준에서 정의된 변수(vars: 컨텍스트에 대한 값)를 제공할 수 있습니다(완전한 vars 컨텍스트 지원은 act에서 제한될 수 있음). --var 플래그나 --var-file를 사용하여 제공할 수 있습니다. 비밀과 비슷합니다.
  • 환경 변수: 워크플로우 실행을 위해 사용자 정의 환경 변수를 설정하려면 --env 플래그 또는 --env-file를 사용하십시오.
act --env NODE_ENV=development --env CUSTOM_FLAG=true
act --env-file .env_vars

러너 환경 및 이미지 관리

기본 러너 이미지(Micro, Medium, Large)는 많은 시나리오를 처리하지만 더 많은 제어가 필요할 때가 있습니다.

1. 기본 이미지의 한계

기본 act 러너 이미지(특히 Micro 및 Medium)는 GitHub에서 제공하는 환경과 동일하지 않습니다. 이들은 워크플로우가 기대하는 특정 도구, 라이브러리 또는 시스템 서비스(예: Docker 컨테이너에서 쉽게 사용할 수 없는 systemd)가 없을 수 있습니다. Large 이미지는 더 높은 정확도를 제공하지만 상당한 크기 단점이 있습니다.

2. -P를 사용하여 대체 이미지 지정

작업이 기본 이미지에 없는 특정 환경이나 도구 세트를 요구하는 경우, -P (플랫폼) 플래그를 사용하여 특정 플랫폼에 대해 다른 Docker 이미지를 사용하도록 act에 지시할 수 있습니다.

형식은 -P <platform>=<docker-image>입니다.

  • <platform>: 워크플로우의 runs-on: 지시문에서 사용하는 레이블(예: ubuntu-latest, ubuntu-22.04, ubuntu-20.04)입니다.
  • <docker-image>: 사용할 Docker 이미지의 전체 이름입니다(예: node:18, python:3.10-slim, mcr.microsoft.com/devcontainers/base:ubuntu).

예시:

# ubuntu-22.04에서 실행되는 작업에 대해 Large 이미지를 사용
act -P ubuntu-22.04=ghcr.io/catthehacker/ubuntu:full-22.04

# ubuntu-latest 작업을 위해 특정 Node.js 버전 사용
act -P ubuntu-latest=node:18-bullseye

# nektos/act-environments에서 더 완벽한 이미지 사용(매우 큼!)
# 경고: nektos/act-environments-ubuntu:18.04는 18GB 이상입니다.
act -P ubuntu-18.04=nektos/act-environments-ubuntu:18.04

# 워크플로우에서 여러 플랫폼을 사용하는 경우 여러 플랫폼 지정
act -P ubuntu-20.04=node:16-buster -P ubuntu-22.04=node:18-bullseye

3. 로컬 러너 이미지 사용(--pull=false)

기본적으로 act는 실행 시마다 지정된 Docker 이미지의 최신 버전을 가져오려고 합니다. 사용자 지정 러너 이미지를 로컬에서 빌드했거나 캐시된 정확한 버전을 사용하려는 경우, 이 동작을 비활성화할 수 있습니다:

act --pull=false
# 또는 오프라인 모드를 사용할 수 있습니다.
act --action-offline-mode

이는 act에게 로컬에서 사용 가능한 이미지가 있을 경우 이를 사용하고 결여된 경우에만 가져오기를 시킵니다.

4. 호스트에서 네이티브로 실행(-self-hosted)

macOS 또는 Windows(runs-on: macos-latest 또는 runs-on: windows-latest)를 대상으로 하는 워크플로우의 경우, act를 동일한 호스트 운영 체제에서 실행 중이라면 act가 러너 자체를 컨테이너로 사용하지 않도록 명령할 수 있습니다. 대신, 단계가 호스트 머신에서 직접 실행됩니다. Docker 호환성에 문제가 있거나 호스트 리소스에 직접 접근해야 할 경우 유용할 수 있습니다.

# macos-latest 작업을 Mac 호스트에서 직접 실행
act -P macos-latest=-self-hosted

# windows-latest 작업을 Windows 호스트에서 직접 실행
act -P windows-latest=-self-hosted

주의: 호스트에서 직접 실행하는 것은 Docker가 제공하는 격리를 우회합니다. 워크플로우 단계는 파일 시스템에 접근할 수 있으며, 잠재적으로 호스트 환경을 수정할 수 있습니다. 이 옵션은 주의하여 사용하세요. 서비스 컨테이너나 컨테이너 작업 등에서 명시적으로 Docker 컨테이너를 사용하는 작업 단계는 여전히 Docker를 사용할 것입니다.

제한 사항 및 고려 사항

act는 매우 유용하지만 그 한계에 인식하는 것이 중요합니다:

  • 완벽한 복제본이 아님: act는 GitHub Actions 환경을 시뮬레이션하지만 동일하지 않습니다. 네트워킹, 사용 가능한 시스템 서비스(예: Docker 컨테이너에서 systemd 없음), 특정 하드웨어 리소스 및 정확한 사전 설치된 도구 세트(매우 큰 러너 이미지를 사용하지 않는 한)에 차이가 있습니다. 복잡한 워크플로우(특히 기본 OS와 또는 특정 GitHub 기능과 많이 상호작용하는 경우)는 act에서 GitHub에서와는 다르게 동작할 수 있습니다.
  • 컨텍스트 차이: github 컨텍스트의 일부는 로컬에서 실행할 때 불완전하거나 기본/모의 값이 포함될 수 있습니다. secrets 컨텍스트는 항상 명시적 입력이 필요합니다. vars 컨텍스트 지원은 라이브 GitHub 환경에 비해 제한될 수 있습니다.
  • 동시성: act는 일반적으로 needs 종속성에 따라 작업을 순차적으로 실행합니다. GitHub의 여러 러너를 사용하여 독립적인 작업을 동시에 실행할 수 있는 기능을 완벽하게 복제하지 않습니다(하지만 act는 매트릭스 작업을 실행하는 것을 지원하지만 대개 로컬에서 순차적으로 실행됩니다).
  • 호스팅 서비스: 캐싱(actions/cache)과 같은 기능은 다르게 작동하거나 GitHub의 통합 캐싱 서비스와는 다른 구성 요건이 필요할 수 있습니다. 워크플로우에서 정의된 서비스 컨테이너는 act가 해당 서비스에 대해 Docker를 사용하므로 작동해야 합니다.
  • 플랫폼 가용성: Docker가 지원하는 호스트(맥, 윈도우, 리눅스) 내에서 Linux 기반 작업만 실행할 수 있습니다. macos-latest 작업을 실행하려면, 이상적으로는 macOS에서 act가 필요하며(또는 macOS에서 -self-hosted 플래그를 사용), 마찬가지로 windows-latest 작업은 일반적으로 Windows에서 act가 필요합니다(또는 Windows에서 -self-hosted). Docker는 Windows에서 Windows 컨테이너를 실행할 수 있지만 act는 주로 Linux 컨테이너를 중심으로 안정적인 지원을 제공합니다.

추천: act를 사용하여 빠른 개발, 구문 검사, 기본 논리 테스트 및 개별 작업 또는 단계 반복을 수행하십시오. 항상 중요한 변경 사항을 병합하기 전에 GitHub에서 워크플로우를 실행하여 최종 검증을 수행하십시오. 특히 배포 파이프라인에서는 더욱 그렇습니다. 공식 act 문서를 참고하여 상세한 지원 매트릭스 및 알려진 문제를 확인하십시오.

결론

GitHub Actions를 로컬에서 테스트하는 것은 생산성을 크게 향상시키며, 느리고 지루한 디버깅 사이클을 빠르고 반복적인 프로세스로 변환합니다. act CLI 도구는 Docker를 활용하여 로컬 머신에서 GitHub Actions 러너 환경을 시뮬레이션하는 강력하고 유연한 방법을 제공합니다.

act를 워크플로우에 통합함으로써, 다음과 같은 이점을 얻을 수 있습니다:

  • 더 빠른 피드백 루프.
  • 테스트를 위해 GitHub로 푸시하는 것에 대한 의존성 감소.
  • 로컬 작업 러너로서의 Actions 정의 사용 능력.
  • 개선된 디버깅 능력.

이 도구는 한계가 있으며 라이브 GitHub 환경의 완벽한 1:1 대체는 아니지만, act는 다양한 사용 사례를 처리하고 신뢰할 수 있는 GitHub Actions 워크플로우 개발에 수반되는 마찰을 크게 줄입니다. 설치하고 기존 워크플로우를 로컬에서 실행해 보며 글로벌하게 생각하고 로컬에서 행동하는 이점을 경험해 보십시오.

💡
멋진 API 테스트 도구가 필요하신가요? 아름다운 API 문서를 생성하는 데 도움이 됩니다.

개발 팀을 위한 통합된 올인원 플랫폼이 필요하신가요? 최대 생산성으로 함께 작업할 수 있도록 도와드립니다.

Apidog는 모든 요구 사항을 충족하며, Postman을 훨씬 더 저렴한 가격에 대체합니다!
버튼