GitHub Actions란? 동작 원리와 Workflow·Job·Runner·Step 쉽게 이해하기

 

 

 

Github Actions는 저장소에서 발생한 이벤트를 감지해, 미리 정의한 작업을 Runner에서 실행하는 이벤트 기반 실행 엔진

 

이벤트 발생
↓
Workflow 선택
↓
Job 실행 조건 판단
↓
Runner 할당
↓
Step 순차 실행
↓
결과 및 로그 저장

 

 

 

 

 

 

Event : 언제 실행할 것인가

---

저장소에서 이벤트, 사건이 발생하면 Workflow 실행이 시작됩니다.

 

on:
  push:
    branches:  [main]

 

대표적인 이벤트로는

• push: 코드가 푸시됨
• pull_request : PR 생성, 수정
• workflow_dispatch: 사용자가 수동 실행
• schedule: 정해진 시간에 실행
• release : 릴리즈 생성

on은 트리거(이벤트 발생) 조건이다.

 

 

 

Workflow  : 무엇을 실행할 것인가

---

. github/

   ㄴworkflows/

        ㄴ ci.yml

 

 

GitHub는. github/workflows 아래의 YAML 파일을 Workflow로 인식한다.

하나의 저장소에 여러 Workflow를 둘 수도 있다.

 

 

ci.yml → 테스트

deploy.yml  → 배포

security.yml  → 보안 검사

 

 

 

job : 실행 작업을 어떻게 나눌 것인가

---

Workflow는 하나 이상의 Job으로 구성된다.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
        - run: echo "테스트 실행"
  deploy:
    runs-on: ubuntu-latest
    steps:
         - run: echo "배포 실행"

 

job은 기본적으로 서로 병렬 실행된다.

즉, test와 deploy가 순차적으로 실행되지 않고 각자 실행됩니다.

 

순서를 지정하려면 needs를 사용한다.

 

deploy:
  needs: test

test 성공 → deploy 실행
test 실패 → deploy 실행 안됨

 

 

 

 

Runner : 어디에서 실행할 것인가.

---

Runner는 Job을 실제로 실행하는 컴퓨터이다.

 

runs-on: ubuntu-latest

 

깃허브는 많은 OS Runner를 제공하지만 직접 서버를 등록하는 Self-hosted Runner도 있다.

중요한 점은 각 Job이 일반적으로 독립된 Runner 환경에서 실행된다는 것이다.

따라서 Job이 다르면 파일과 메모리가 자동으로 공유되지 않는다. 결과물을 넘기려면 Artifact, Cache, Job Output 등을 사용해 넘겨야 한다.

 

 

Step : 어떤 순서로 실행할 것인가

---

job 내부의 Step은 위에서 아래로 순차 실행된다.

steps:
  - uses: actions/checkout@v4

  - name: 테스트 실행
    run: ./gradlew test

 

Step은 두 가지 형태가 있다.

uses : 만들어진 Action 사용

run : Runner에서 명령어 직접 실행

 

actions/checkout은 저장소 코드를 Runner로 가져오는 Action이다. Runner에 코드가 자동으로 들어오는 게 아니라는 점이 포인트이다.

 

 

 

한 번에 연결해서 확인

name: CI

on:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: 저장소 코드 가져오기
        uses: actions/checkout@v4

      - name: 테스트 실행
        run: ./gradlew test

 

해석하자면

 

main 브랜치에 코드가 푸시되면 CI Workflow를 생성하고, Ubuntu Runner를 할당한 뒤 저장소 코드를 내려받아 테스트를 실행한다.

 

핵심 정리

Event → Workflow → Job → Runner → Step

 

위와 같은 역할들은

Github에서 준비한 Runner 컴퓨터에서 순차적, 병렬적으로 실행되는 거다.

작업을 Runner로 전달해서 명령어, 빌드, 테스트를 실행하고 HTTPS API 요청을 AWS로 보내는 방식이다.

 

물론 AWS는 Runner를 믿지 않아서 인증정보를 등록해 둬야 CI/CD 파이프 라인을 자동화할 수 있는 것이다.

 

 

쉽게 말하면

코드를 올리면 컴퓨터가 약속해 둔 일을 알아서 해주는 기능.
코드가 잘 작동하는지 검사하고, 문제가 없으면 서버에 전달하는 일까지 해준다.
일은 사용자가 정의할 수 있다.

 

 

추가적으로

Workflow 구성, 실행 흐름을 추가적으로 공부하고

Github Secrets를 공부해야 하고

AWS 연동방법까지 공부해야 합니다.

 

읽어주셔서 감사합니다.