사용자 지정 GitHub 작업 만들기
GitHub Actions는 사용자 자체 리포지토리를 이용해 편안하고 편리하게 코드를 클라우드로 옮길 수 있는 강력한 기능입니다. 여기에서는 다른 유형의 GitHub 작업과 사용자 지정 GitHub 작업을 만들기 위한 메타데이터, 구문, 워크플로 명령에 관해 알아봅니다.
GitHub 작업의 유형
Actions는 개발 워크플로를 사용자 지정하는 데 사용할 수 있는 개별 작업입니다. 리포지토리와 상호 작용하는 사용자 지정 코드를 작성하여 사용자 지정 작업을 수행하거나, GitHub 커뮤니티에서 공유하는 작업을 사용하여 사용자 고유의 작업을 만들 수 있습니다. 다양한 작업을 탐색하면 Docker 컨테이너 작업, JavaScript 작업과 복합 실행 단계 작업라는 세 가지 유형의 작업이 있음을 알게 됩니다. 각 작업 유형을 자세히 살펴보겠습니다.
Docker 컨테이너 작업
Docker 컨테이너는 GitHub Actions 코드로 환경을 패키지합니다. 이는 모든 종속성이 해당 컨테이너 내에 있기 때문에 작업이 일관되고 안정적인 환경에서 실행됨을 의미합니다. 작업을 특정 환경 구성에서 실행해야 하는 경우에는 운영 체제 및 도구를 사용자 지정할 수 있는 Docker 컨테이너를 사용하는 것이 좋습니다. 단점은 컨테이너를 빌드하고 검색해야 하므로 Docker 컨테이너 작업이 JavaScript 작업보다 느린 경우가 있다는 것입니다.
Docker 컨테이너 작업을 빌드하기 전에 환경 변수 및 Docker 컨테이너 파일 시스템을 사용하는 방법에 대한 기본적인 이해가 있어야 합니다. Docker 컨테이너 작업을 빌드하기 위한 단계는 최소한의 수준으로 간단합니다.
-
Dockerfile을 만들어 Docker 이미지를 조합하는 명령을 정의합니다. -
action.yml메타데이터 파일을 만들어 작업의 입력과 출력을 정의합니다. 파일에서runs: using:값을docker로 설정하고runs: image:값을Dockerfile로 설정합니다. -
entrypoint.sh파일을 만들어 Docker 이미지를 설명합니다. - 다음
action.yml,entrypoint.sh,Dockerfile,README.md파일을 사용하여 작업을 GitHub에 커밋하고 밀어넣습니다.
JavaScript 작업
JavaScript 작업은 실행기 머신에서 직접 실행할 수 있으며, 작업을 실행하는 데 사용하는 환경에서 작업 코드를 분리할 수 있습니다. 이로 인해 작업 코드가 단순화되고 Docker 컨테이너 내의 작업보다 빠르게 실행될 수 있습니다.
패키지된 JavaScript 작업을 만들고 사용하기 위한 필수 조건으로 npm이 포함된 Node.js를 다운로드해야 합니다. 선택적인 (하지만 당사에서 권장하는) 단계는 좀 더 일관적이고 신속하게 JavaScript 작업을 빌드할 수 있는 Node.js 패키지의 컬렉션인 GitHub Actions Toolkit Node.js를 사용하는 것입니다.
JavaScript 작업을 빌드하는 단계는 최소 수준이며 간단합니다.
- 작업의 입력 및 출력을 정의하는
action.yml메타데이터 파일을 만들고 이 JavaScript 작업을 실행하는 방법을 작업 실행기에 알려줍니다. - 도구 키트 패키지, 라우팅, 작업의 기타 기능에 대한 컨텍스트 정보를 사용하여
index.js파일을 만듭니다. - 다음
action.yml,index.js,node_modules,package.json,package-lock.json,README.md파일을 사용하여 작업을 GitHub에 커밋하고 밀어넣습니다.
복합 실행 단계 작업
복합 실행 단계 작업을 사용하면 셸 스크립트를 사용하여 작업을 다시 사용할 수 있습니다. 동일한 작업 내에서 여러 셸 언어를 혼합할 수도 있습니다. 여러 작업을 자동화하는 다양한 셸 스크립트가 있는 경우, 이제 이러한 스크립트를 작업으로 쉽게 전환하고 다른 워크플로에 다시 사용할 수 있습니다. 때로는 JavaScript를 사용하거나 코드를 Docker 컨테이너에 래핑하는 것보다 셸 스크립트를 작성하기가 더 쉽습니다.
패키징된 복합 작업
패키지된 복합 작업은 여러 단계를 재사용 가능한 단위로 패키지로 묶습니다. 이러한 작업은 리포지토리에 정의되며 여러 리포지토리의 워크플로에서 참조할 수 있습니다. 복합 작업을 패키징하면 워크플로가 간소화되고 중복성이 감소하며 유지 관리 효율성이 향상됩니다.
패키지된 복합 작업을 만들 때 단계는 단일 action.yml 파일에 정의됩니다. 이 파일은 실행할 명령 또는 작업의 입력, 출력 및 시퀀스를 지정합니다. 패키지된 복합 작업은 반복 작업을 자동화하거나 여러 셸 명령을 재사용 가능한 단일 작업으로 결합하는 데 특히 유용합니다.
복합 동작 만들기
1. 복합 작업에 대한 디렉터리 설정
복합 작업을 리포지토리 내의 자체 디렉터리에 배치해야 합니다.
디렉터리 구조 예제:
.github/actions/my-composite-action/
├── action.yml
└── scripts/
└── my-script.sh
2. 파일 정의 action.yml
my-composite-action 디렉터리 내부에 action.yml 파일을 만듭니다.
name: "My Composite Action"
description: "A reusable composite action that checks out code and sets up Node.js"
inputs:
node-version:
description: "The Node.js version to use"
required: true
runs:
using: "composite"
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: ${{ inputs.node-version }}
메모: using: "composite" 필드는 이 작업이 복합 작업임을 나타냅니다.
3. 워크플로에서 복합 작업 사용
복합 작업이 만들어지면 GitHub Actions 워크플로에서 참조할 수 있습니다.
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Use my composite action
uses: ./.github/actions/my-composite-action
with:
node-version: '18'
복합 작업이 다른 리포지토리에서 공유되는 경우 다음과 같이 참조합니다.
uses: owner/repository/.github/actions/my-composite-action@v1
복합 작업에 출력 추가
복합 작업은 워크플로가 단계 또는 작업 간에 데이터를 전달하는 데 사용할 수 있는 출력을 정의할 수 있습니다. 출력은 한 작업에서 다른 작업으로 결과 또는 계산 값을 공유하는 데 특히 유용합니다.
다음 예제에서는 복합 작업에서 출력을 정의하고 사용하는 방법을 보여 줍니다.
action.yml에서 출력을 정의하십시오.
action.yml 파일은 script-result라는 이름의 출력을 지정합니다. 이 출력은 result 단계의 run-script 출력에서 값을 검색합니다. 이 단계에서는 run-script Bash 명령을 실행하여 출력 값을 설정합니다.
outputs:
script-result:
description: "Result from the script"
value: ${{ steps.run-script.outputs.result }}
runs:
using: "composite"
steps:
- id: run-script
run: echo "result=Success" >> $GITHUB_OUTPUT
shell: bash
워크플로에서 출력 사용
복합 작업이 만들어지면 워크플로에서 해당 출력에 액세스할 수 있습니다. 예제는 다음과 같습니다.
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Run composite action
id: my-action
uses: ./.github/actions/my-composite-action
- name: Display result
run: echo "Script Result: ${{ steps.my-action.outputs.script-result }}"
이 예제에서:
- 복합 작업은 키워드를
uses사용하여 호출됩니다. -
script-result구문을 사용하여steps.<step-id>.outputs.<output-name>출력에 액세스합니다. - 워크플로 로그에 결과를 표시합니다.
복합 작업에서 출력을 정의하여 재사용 가능한 모듈식 워크플로를 만듭니다. 이 방법을 사용하면 데이터 공유가 간소화되고 유지 관리 효율성이 향상됩니다.
복합 작업에 대한 모범 사례
| 모범 사례 | 설명 |
|---|---|
| 버전 관리 사용 | 태그를 v1 사용하여 안정적인 버전 1을 참조합니다. |
| 모듈식 작업 유지 | 복합 작업 내에서 관련 단계를 그룹화합니다. |
| 문서 입력 및 출력 | 에서 입력/출력에 대한 설명을 추가합니다 action.yml. |
| 게시하기 전에 테스트 | 테스트 리포지토리에서 복합 작업의 유효성을 검사합니다. |
워크플로의 복합 작업
복합 작업은 여러 단계를 재사용 가능한 단위로 번들로 묶어 워크플로를 간소화하는 강력한 방법입니다. 이러한 작업을 사용하면 단일 action.yml 파일에서 명령 또는 작업 시퀀스를 정의하여 워크플로 전체에서 논리를 더 쉽게 유지 관리하고 재사용할 수 있습니다.
복합 작업의 이점:
- 재사용성 - 작업을 한 번 정의하고 여러 워크플로에서 사용합니다.
- 유지 관리 기능 - 단일 작업에서 논리를 중앙 집중화하여 중복을 줄입니다.
- 모듈성 - 여러 셸 명령 또는 다른 작업을 단일 단위로 결합합니다.
GitHub Actions 실행기에서 CLI를 설정하는 작업 개발
많은 CI/CD 워크플로에는 클라우드 서비스와 상호 작용하거나 인프라를 관리하거나 스크립트를 실행하기 위해 특정 버전의 CLI 도구 가 필요합니다. GitHub 호스팅 실행기는 많은 도구와 함께 미리 설치되지만, 특히 이전 또는 지원되지 않는 버전인 경우 워크플로에 필요한 정확한 버전을 포함하지 않을 수 있습니다. 모든 워크플로에서 필요한 CLI 버전을 설치하는 대신 재사용 가능한 GitHub 작업을 만들 수 있습니다.
- 작업 간에 필요한 CLI 버전을 일관되게 설치합니다.
- 설치 논리를 중앙 집중화하여 워크플로를 간소화합니다.
- 더 빠른 워크플로 실행을 위해 캐싱을 최적화합니다.
CLI 설정 작업을 개발하는 방법
CLI 설정 작업은 GitHub 실행기에서 CLI를 설치하고 구성하는 JavaScript 기반 작업입니다.
작업을 만드는 단계:
1단계: 작업 디렉터리 설정
CLI 설정 작업에 대한 디렉터리를 수동으로 만들려면 다음 단계를 수행합니다.
- 리포지토리로 이동
작업에 대한 새 디렉터리 만들기
폴더 내에my-cli-action이름이 지정된.github/actions새 디렉터리를 만듭니다. 이렇게 하면 작업이 구성되고 사용자 지정 작업에 대한 GitHub의 권장 구조를 따릅니다.새 디렉터리로 이동합니다.
새로 만든 디렉터리로 변경하여 작업에 대한 파일 추가를 시작합니다.디렉터리 구조 확인
디렉터리를 만든 후 리포지토리 구조는 다음과 같이 표시됩니다.
your-repository/
├── .github/
│ ├── actions/
│ │ ├── my-cli-action/
이제 CLI 설정 작업에 필요한 action.yml 파일 및 기타 중요한 파일을 생성하는 작업을 진행할 준비가 되었습니다.
2단계: action.yml 메타데이터 파일 정의
작업을 설명하는 action.yml 파일을 만듭니다.
name: "Setup MyCLI"
description: "Installs MyCLI and adds it to the PATH"
author: "Your Name"
inputs:
version:
description: "The CLI version to install"
required: false
default: "latest"
runs:
using: "node16"
main: "index.js"
다음을 사용하는 이유: node16 이 작업은 Node.js 16을 사용하여 JavaScript 코드를 실행합니다.
3단계: CLI를 설치하는 JavaScript 스크립트 만들기
동일한 디렉터리에서 index.js 파일을 만들고 다음 코드를 추가합니다.
const core = require('@actions/core');
const { execSync } = require('child_process');
async function run() {
try {
const version = core.getInput('version') || 'latest';
console.log(`Installing MyCLI version: ${version}...`);
execSync(`curl -fsSL https://cli.example.com/install.sh | sh`, { stdio: 'inherit' });
console.log("MyCLI installed successfully.");
} catch (error) {
core.setFailed(`Installation failed: ${error.message}`);
}
}
run();
위의 JavaScript 코드는 core.getInput()을 사용하여 입력으로 지정된 CLI 버전을 검색합니다. 그런 다음 curl 명령을 실행하여 CLI를 다운로드하고 설치합니다. 설치 프로세스가 실패하면 작업은 core.setFailed()를 사용하여 워크플로를 실패로 표시합니다.
4단계: 로컬에서 작업 테스트
워크플로에서 작업을 사용하기 전에 GitHub 호스팅 실행기에서 테스트합니다.
리포지토리에 워크플로 파일(.github/workflows/test.yml)을 만듭니다.
name: Test MyCLI Setup
on:
push:
branches:
- main
- feature/*
1. 워크플로 시작하기
워크플로는 주 분기 및 기능/* 패턴과 일치하는 모든 분기로 푸시할 때 트리거됩니다. 리포지토리의 분기 전략에 맞게 조정할 수 있습니다.
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
2. 리포지토리 복제
작업/checkout@v4 작업은 리포지토리를 러너에 복제하는 데 사용됩니다. 이렇게 하면 워크플로가 리포지토리의 파일에 액세스할 수 있습니다.
- name: Install MyCLI
uses: ./.github/actions/my-cli-action
with:
version: '1.2.3'
3. 사용자 지정 작업 실행
사용: ./.github/actions/my-cli-action 줄은 사용자 지정 작업을 로컬로 참조합니다. 작업 디렉터리와 action.yml 파일이 올바르게 설정되어 있는지 확인합니다. 버전 입력은 설치할 CLI 버전(이 경우 버전 1.2.3)을 지정합니다.
- name: Verify CLI Installation
run: |
echo "Checking MyCLI version..."
mycli --version
4. CLI 설치 확인
이 단계에서는 셸 명령을 실행하여 CLI가 성공적으로 설치되었는지 확인합니다. mycli --version을 실행하여 설치된 CLI의 버전을 확인합니다.
로컬에서 테스트
이 워크플로를 로컬로 테스트하려면 CLI 도구를 사용합니다 act .
act -j test
이렇게 하면 로컬 컴퓨터에서 GitHub Actions 환경을 시뮬레이션하여 변경 내용을 푸시하기 전에 워크플로를 디버그하고 유효성을 검사할 수 있습니다.
최적화 팁: 캐싱
워크플로 성능을 향상시키려면 다음 작업을 사용하여 CLI 설치 디렉터리를 캐시합니다 actions/cache .
- name: Cache MyCLI
uses: actions/cache@v4
with:
path: ~/.mycli
key: mycli-${{ runner.os }}-${{ inputs.version }}
이렇게 하면 후속 실행에서 캐시된 CLI 설치를 다시 사용하여 설치 시간을 단축할 수 있습니다.
CLI 설정 작업에 대한 모범 사례
| 모범 사례 | 설명 |
|---|---|
| 버전 관리 사용 | 사용자가 .를 통해 CLI 버전을 지정할 수 있도록 허용합니다 inputs.version. |
| 오류 제대로 처리 | 오류 발생시 종료하는 데 사용합니다 core.setFailed() . |
| 캐시 CLI 설치 |
actions/cache을 사용하여 워크플로 성능을 최적화하십시오. |
| 설명서 제공 |
README.md에서 사용법 및 입력에 대해 설명합니다. |
JavaScript 작업 문제 해결
JavaScript 기반 GitHub Actions를 사용하는 경우 워크플로 실행 중에 예기치 않은 동작, 오류 또는 오류가 발생할 수 있습니다. 이 단원에서는 JavaScript 작업에서 문제를 식별하고 해결하는 데 도움이 되는 기술과 도구를 제공합니다.
일반적인 문제 해결 시나리오
| 문제 | 가능한 원인 | 제안된 수정 |
|---|---|---|
| 스택 추적으로 작업 실패 |
index.js에서 구문 또는 런타임 오류 |
console.log()를 사용하고 로그를 확인하십시오. |
입력은 다음과 같습니다. undefined |
잘못된 입력 이름 또는 누락된 입력 |
action.yml을(를) 확인하고 입력이 전달되는 방법을 검토하십시오. |
| 환경 변수가 설정되지 않음 |
core.exportVariable 또는 process.env 제대로 사용되지 않음 |
변수 설정 코드 검토 |
| 파일을 찾을 수 없음 | 상대 경로 누락 |
__dirname 또는 파일의 전체 경로 사용 |
| 캐시가 복원되지 않음 | 잘못된 key 값 또는 path 값 |
캐시 구성 및 키 확인 |
디버깅에 로깅 사용
core.info, core.debug, console.log 메시지 기록
const core = require('@actions/core');
core.info("This is an info message");
core.debug("This is a debug message");
console.log("This is a raw console log");
✅ 디버그 로그에 core.debug를 사용합니다. ACTIONS_STEP_DEBUG true로 설정된 경우에만 표시됩니다.
디버그 로깅 활성화
다음 비밀을 설정하여 단계 수준 디버그 로그를 사용하도록 설정할 수 있습니다.
ACTIONS_STEP_DEBUG=true
실행기 진단 로그를 사용하도록 설정하려면 다음을 설정합니다.
ACTIONS_RUNNER_DEBUG=true
디버깅을 위한 비밀 설정
- GitHub 리포지토리로 이동합니다.
- 설정>비밀 및 변수 작업으로> 이동합니다.
- 다음 이름과 값을 사용하여 새 비밀을 추가합니다.
-
ACTIONS_STEP_DEBUG:
true -
ACTIONS_RUNNER_DEBUG:
true
-
ACTIONS_STEP_DEBUG:
워크플로 로그 검사
워크플로가 실패하면 작업 탭에서 실패한 작업을 클릭합니다. 각 단계를 다음으로 확장합니다.
- 자세한 로그 보기
- 표준 출력 확인(stdout)
- 스크립트의 종료 코드 참조
- 처리되지 않은 예외 식별
🔍 예제 로그 출력
Error: Cannot find module '@actions/core'
Require stack:
- /home/runner/work/_actions/my-org/my-action/index.js
✅ 수정: npm install 명령을 실행하고 node_modules 커밋하거나, 또는 ncc를 사용하여 액션을 번들로 묶습니다.
로컬로 작업 테스트
ACT - CLI 도구를 사용하여 GitHub Actions를 로컬로 실행합니다. 예제:
act -j test
🛠 로컬로 테스트할 때 GitHub 환경을 제대로 시뮬레이션해야 합니다.
오류를 정상적으로 처리
예외를 catch하고 도움이 되는 메시지로 실패를 알려 줍니다.
try {
// your logic
} catch (error) {
core.setFailed(`Action failed with error: ${error.message}`);
}
🔁 이렇게 하면 GitHub가 오류 발생 시 워크플로를 중지하고 읽을 수 있는 로그를 제공합니다.
JavaScript 작업 디버깅 모범 사례
| 연습 | 설명 |
|---|---|
| core.debug() 사용 | 디버깅이 활성화되지 않은 경우, 자세한 로그를 숨깁니다. |
| action.yml 유효성 검사 | 입력 및 출력이 올바르게 정의되었는지 확인합니다. |
| 번들 코드 | JavaScript를 단일 파일로 컴파일하는 데 사용합니다 @vercel/ncc . 이렇게 하면 종속성이 줄어들고 필요한 모든 모듈이 포함되어 파일 누락으로 인한 런타임 오류를 방지할 수 있습니다. |
| 행동으로 테스트 | 빠른 반복을 위해 로컬에서 실행을 시뮬레이션합니다. |
| try/catch 사용 | 워크플로가 자동으로 실패하지 않도록 방지합니다. |
Docker 컨테이너 작업 문제 해결
Docker 컨테이너 작업은 GitHub Actions 워크플로에서 복잡한 도구 및 환경을 캡슐화하는 데 강력합니다. 그러나 격리된 런타임 환경으로 인해 이러한 작업을 디버깅하는 것이 JavaScript 작업보다 더 어려울 수 있습니다. 이 단원에서는 Docker 기반 작업의 문제를 식별, 진단 및 해결하는 작업을 안내합니다.
Docker 컨테이너 작업의 일반적인 문제
| 문제 | 원인 | 제안된 수정 |
|---|---|---|
| 작업을 시작하지 못함 |
ENTRYPOINT 또는 CMD 잘못 구성됨 |
Dockerfile이 ENTRYPOINT를 올바르게 사용하는지 확인 |
| 누락된 종속성 | 종속성이 설치되지 않았거나 잘못 구성됨 | 모든 패키지가 이미지에 설치되어 있는지 확인 |
| 입력이 수신되지 않음 |
INPUT_ 액세스되지 않는 환경 변수 |
process.env.INPUT_<INPUT_NAME>을 사용 (또는 해당하는 셸) |
| 파일을 찾을 수 없음 | 컨테이너 내의 잘못된 파일 경로 | 절대 경로 사용 또는 디렉터리 구조 유효성 검사 |
| 사용 권한이 거부됨 | 파일 또는 스크립트에 실행 권한이 없음 | Dockerfile에 추가 RUN chmod +x <script> |
| 네트워크 관련 오류 | 외부 서비스에 액세스할 수 없음 | 네트워크 설정 유효성 검사 및 논리 다시 시도 |
Docker 작업 수명 주기 이해
문제를 해결하기 전에 Docker 컨테이너 작업이 실행되는 방법을 이해하는 것이 유용합니다.
1. 워크플로 트리거
GitHub Actions 워크플로는 설정된 이벤트(push, pull_request, 수동 workflow_dispatch 등의)에 대한 응답으로 시작됩니다.
2. 러너 설정
GitHub는 워크플로를 실행하기 위해 새 가상 머신( 실행기)을 프로비전합니다. 실행기는 작업 정의를 다운로드하고 종속성을 확인하여 환경을 준비합니다.
3. 작업 해결
작업이 runs.using: docker 파일의 action.yml에 지정되어 있으면 GitHub는 이를 Docker 기반 작업으로 인식합니다.
4. 이미지 빌드 또는 끌어오기
GitHub는 작업에 Dockerfile 정의된 Docker 이미지를 빌드하거나 지정된 경우 미리 빌드된 이미지를 가져옵니다. 이 이미지는 작업 코드가 실행되는 환경을 정의합니다.
5. 컨테이너 실행
실행기는 Docker 컨테이너를 시작하고, 작업 영역을 탑재하고, 워크플로에 정의된 비밀 및 입력을 포함하여 환경 변수를 삽입합니다.
6. 진입점 실행
GitHub는 컨테이너 내의 Dockerfile에서 명령을 실행합니다 entrypoint . 여기서 사용자 지정 작업 논리는 일반적으로 스크립트 또는 애플리케이션을 실행합니다.
7. 결과 처리
컨테이너 작업에 의해 설정된 모든 출력은 실행기에서 캡처되고 워크플로의 후속 단계에 전달됩니다. 완료되면 컨테이너가 종료되고 실행기는 삭제됩니다.
참고: Docker 컨테이너 작업은 깨끗하고 격리된 환경에서 실행됩니다. 파일 시스템 상태, 설치된 도구 및 환경 변수는 모두 Dockerfile 내에서 정의되어야 합니다.
디버깅 기술
1. 로깅 추가
진입점 스크립트에서 echo, printf 또는 로깅 문을 사용합니다.
echo "Starting Docker action..."
echo "Input VALUE: $INPUT_VALUE"
모든 중요한 입력 및 단계를 기록하여 오류가 발생하는 위치를 진단합니다.
2. 로컬로 빌드 및 테스트
컴퓨터에서 Docker를 사용하여 컨테이너 동작을 시뮬레이션합니다.
docker build -t my-action .
docker run -e INPUT_NAME=value my-action
환경 변수가 GitHub 집합과 유사한지 확인합니다.
3. ACT CLI를 사용하여 GitHub 워크플로 시뮬레이션
GitHub 워크플로를 로컬로 실행하는 작업을 설치합니다.
act -j test-job
GitHub로 푸시하지 않고 워크플로에서 Docker 작업을 테스트하는 데 적합합니다.
4. Dockerfile 구성 유효성 검사
ENTRYPOINT 또는 CMD를 정의해야 합니다. 스크립트를 이미지에 복사하고 실행 권한을 부여합니다.
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
5. GitHub 로그 검사
실패한 워크플로 실행을 클릭한 후 각 단계를 확장하여 다음을 검사합니다.
- Docker 빌드 로그
- 컨테이너의 표준 출력 및 표준 오류
- 종료 코드 및 스택 추적 🔍 로그는 종종 누락된 패키지, 구문 문제 또는 권한 오류를 표시합니다.
예: 진입점 오류
Error: container_linux.go:380: starting container process caused "exec: \"/entrypoint.sh\": permission denied"
✅ 수정: Dockerfile에 RUN chmod +x /entrypoint.sh 추가합니다.
환경 변수 매핑
| GitHub 입력 | Docker 환경 변수 |
|---|---|
with: name: test |
INPUT_NAME=test |
GITHUB_WORKSPACE |
에 매핑됨 /github/workspace |
GITHUB_EVENT_NAME |
워크플로를 트리거한 이벤트 |
echo "Input was $INPUT_NAME"
echo "Working dir: $GITHUB_WORKSPACE"
문제 해결 비밀 사용
리포지토리 또는 조직에 다음 비밀을 추가하여 추가 로깅을 사용하도록 설정합니다.
| 비밀 | 설명 |
|---|---|
ACTIONS_STEP_DEBUG |
디버그 로그 활성화 |
ACTIONS_RUNNER_DEBUG |
실행기 진단 사용 |
Docker 작업 디버깅에 대한 모범 사례
| 모범 사례 | 이유 |
|---|---|
| 넉넉하게 로깅 사용 | 오류 지점을 추적하는 데 도움이 됩니다. |
| 항상 chmod +x 설정 | 셸 스크립트에 대한 권한 오류 방지 |
| 스크립트에서 입력 유효성 검사 | 누락되거나 형식이 잘못된 입력을 조기에 발견하십시오. |
| 컨테이너 종속성 최소화 | 더 작은 이미지는 디버그하기 쉽습니다. |
| docker 실행 또는 동작을 사용하여 로컬로 테스트 | 더 빠른 반복 및 즉각적인 피드백 |