dev.to

The minimum you need to know about GitHub Actions

GitHub Actions를 시작할 때 알아야 할 최소한의 내용

GitHub Actions의 워크플로 파일에 필요한 on과 jobs 항목을 설명하고, 푸시·예약·수동 실행을 설정하는 방법을 Hugo 사이트 배포 사례로 보여줍니다. 여섯 줄짜리 hello 워크플로로 실행 로그를 확인하는 방법도 안내합니다.

에디터 노트

초보자가 트리거와 작업의 관계를 익히는 데는 hello 워크플로가 적절하고, Hugo 예시는 실제 단계가 어떻게 이어지는지 보여줍니다. 다만 Hugo 예시의 npm ci 명령 끝에 붙은 || true는 lockfile이 없어 설치를 건너뛰는 경우뿐 아니라 설치 오류까지 성공으로 넘길 수 있습니다. 댓글이 지적한 이 조건은 실제 배포 워크플로의 실패 감지와 직결됩니다. 예약 실행과 푸시 실행이 겹칠 때의 처리 방식은 질문으로 남았고 원문은 답을 제시하지 않습니다. 따라서 이 글은 기본 구성과 로그 확인법을 안내하는 입문 자료로 읽는 것이 맞습니다. 자동 배포에 필요한 동시 실행 제어나 오류 처리까지 다루지는 않습니다.

AI 요약

GitHub Actions는 지정한 이벤트가 발생하면 GitHub 서버에서 워크플로를 실행하는 자동화 기능입니다. 글쓴이는 Hugo 사이트를 로컬에서 직접 빌드하고 public/ 디렉터리를 올리던 방식에서 벗어나, 새 글을 푸시하면 빌드와 배포가 자동으로 진행되도록 구성한 사례를 설명합니다. 예약 실행과 수동 실행도 지원합니다.

워크플로 파일과 실행 조건

워크플로 파일은 저장소의 .github/workflows/ 아래에 .yml 또는 .yaml 형식으로 둡니다. 파일 하나에 워크플로 하나를 정의하며, 해당 디렉터리에는 여러 파일을 둘 수 있습니다. 필수 항목은 실행 조건을 정하는 on과 실제 작업을 담는 jobs입니다.

예시의 on 항목은 세 가지 트리거를 사용합니다. push는 main 브랜치에 푸시할 때 실행하고, schedule은 매일 01:26 UTC에 실행합니다. GitHub의 cron 시간은 UTC 기준이라 현지 시간과 변환해야 합니다. workflow_dispatch를 추가하면 저장소의 Actions 탭에서 Run workflow 버튼을 눌러 수동으로 실행할 수 있습니다. 글쓴이는 트리거 설정에서 들여쓰기 수준을 잘못 맞춰 디버깅에 시간을 쓴 경험도 언급합니다.

작업과 단계 구성

jobs 아래에는 작업을 정의합니다. 각 작업은 실행 머신을 지정하는 runs-on과 순서대로 실행할 단계를 담는 steps로 구성합니다. Hugo 예시의 build 작업은 ubuntu-latest에서 Hugo와 Dart Sass를 설치하고, actions/checkout으로 저장소를 가져옵니다. 이어 Pages 설정과 Node.js 의존성 설치를 거쳐 Hugo로 사이트를 빌드하고, public/ 디렉터리를 Pages 아티팩트로 올립니다. 배포 작업은 예시에서 생략했으며 전체 워크플로 링크를 안내합니다.

처음부터 배포를 구성하지 않아도 됩니다. on: push와 ubuntu-latest, echo "hello"를 포함한 간단한 워크플로를 .github/workflows/hello.yml에 저장해 푸시하면 매번 실행됩니다. 이 명령은 로컬 터미널이 아니라 GitHub 호스티드 러너에서 실행되므로 출력은 저장소의 Actions 탭에서 해당 실행과 작업을 열어 로그로 확인합니다.

dev.to 반응

  • @codingwithjiro — 설명이 명확합니다. 포트폴리오 프로젝트에서 비교적 최근부터 GitHub Actions를 쓰고 있는데, 접근 방식이 간결해서 마음에 듭니다.
  • @marcusykim — lockfile이 없을 때만 설치를 건너뛰고 npm ci 실패를 성공으로 처리하지 않는 편이 좋겠습니다. 마지막의 || true는 두 경우를 모두 러너에 성공으로 보이게 하므로, 의존성 설치가 깨져도 Hugo 빌드까지 진행될 수 있습니다. lockfile 존재 여부를 명시적인 if로 처리하면 초보자도 건너뛰는 동작은 유지하면서 실제 설치 오류는 작업을 중단시킬 수 있습니다. 잘못된 lockfile을 넣어 Actions 로그에서 차이를 확인해 보겠습니다.
  • @francistrdev — 이 주제로 글을 쓰려던 참인데 먼저 올리셨네요. 글이 좋고 요점이 분명합니다. GitHub Actions를 CI/CD 워크플로로 창의적으로 쓸 수 있는지 살펴보고 있는데 지금까지 잘 진행되고 있고 매우 편리한 도구입니다. 잘하셨습니다, Julie.
  • @jabinpou — 여섯 줄짜리 hello 워크플로는 배포 세부사항에 가리지 않고 트리거와 작업을 볼 수 있어 좋은 출발점입니다. Hugo 예시에서 예약 빌드와 푸시 트리거 배포가 겹치는 상황을 처리하려면 무엇을 더해야 하나요?

원문: dev.to / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗