GitHub Actions Workflow

GitHub Actions workflow는 "YAML을 실행하는 파일"보다 repository event를 versioned automation으로 변환하는 control plane에 가깝다고 보는 것이 이해에 유리하다. trigger가 언제 실행할지를, job/runner가 어디서 실행할지를, step/action이 무엇을 실행할지를 분리해야 failure의 원인을 좁힐 수 있다.

event가 어떤 YAML version을 실행시키는가

flowchart LR
    E[Repository event / dispatch / schedule] --> T[on: trigger]
    T --> W[Workflow YAML]
    W --> J[Job]
    J --> R[Runner]
    R --> S[Ordered steps]
    S --> A[Script or action]

• workflow는 하나 이상의 job으로 구성된 configurable automated process이며, repository의 .github/workflows directory에 커밋된 YAML file로 정의한다. repository event, manual dispatch, schedule이 workflow run을 시작시킬 수 있다.^[1]
• workflow trigger는 on key로 정의한다. 이벤트가 발생하면 associated commit SHA/ref가 생기고, GitHub는 그 SHA/ref 시점의 .github/workflows에서 on: 조건이 맞는 workflow file을 찾아 실행한다. 따라서 워크플로 실행에 쓰이는 것은 이벤트 시점의 SHA/ref에 있던 version이며, 실행 시 runner 환경에 GITHUB_SHA(commit SHA), GITHUB_REF(Git ref)가 설정된다.^[2]
• job은 runner에서 실행되고, job의 step은 script를 실행하거나 reusable action을 호출한다.^[1:1]

같은 workflow라도 event의 SHA/ref에 있던 file을 사용하므로, default branch에 있는 최신 YAML이 항상 적용된다고 가정하면 안 된다. trigger filter와 source revision은 "왜 실행됐는가"를 설명하는 핵심 evidence라는 관점에서 다뤄야 한다.

GitHub Actions reference는 workflow/job-level permissions, secrets, environments, concurrency, reusable workflow와 action reference를 별도 syntax boundary로 다룬다.^[3] CI workflow를 다룰 때 trigger(언제)·runner/job(어디서)·step/action(무엇을)을 같은 layer로 뭉뚱그리면, event origin별 access boundary나 실행되지 않은 이유를 설명하지 못하게 된다고 보인다.

경계

• on, jobs, steps의 구체 YAML field catalogue는 reference source에 있고, 이 page는 모든 option을 복제하지 않는다.
• secrets와 permissions는 workflow security boundary지만 조직의 secret naming, cloud credential policy, pull_request_target security model의 세부 위협 모델은 별도 source가 필요한 확장 주제다.
• GitLab CI, Jenkins 등은 서로 다른 workflow implementation이며 GitHub Actions syntax와 혼합하지 않는다.
• Docker build는 CI job의 한 step이 될 수 있지만 Dockerfile이 workflow trigger·permission·deployment approval을 대체하지 않는다. Docker Platform은 job에서 build하거나 실행할 수 있는 packaging/runtime 도구이고, workflow의 event·job scheduling을 결정하지 않는다.

실패 모드

• trigger branch/path filter를 확인하지 않아 expected event가 workflow를 실행하지 않는 경우.
• runner, job, step을 같은 execution unit으로 취급해 dependency·failure location·parallelism을 설명하지 못하는 경우.
• workflow source revision과 default branch의 최신 file을 혼동해, 실행된 configuration을 잘못 진단하는 경우.
• permission과 secret availability를 command-level convenience로 취급해 event origin별 access boundary를 놓치는 경우.

관련

• Docker Platform — workflow job은 Docker image build·test·publish를 수행할 수 있지만 Docker는 workflow control plane이 아니다.
• Prometheus — CI 성공은 runtime metric health와 다르므로 delivery verification과 monitoring을 별도로 설계해야 한다.

출처

테스트 질문

• GitHub Actions에서 event, workflow, job, step, runner는 어떤 순서와 책임으로 연결되는가?
• push가 발생했는데 workflow가 실행되지 않았다면 on filter, workflow file 위치, event SHA/ref 중 무엇을 먼저 확인해야 하는가?