Github Actions - Push

push라는 이벤트가 발생했을때(리포지토리에 커밋이 푸시될때) 자동으로 워크플로우가 실행되도록 하는 워크플로우를 만들어보려고 한다.

 

먼저 깃허브에서 프로그램을 하나 클론을 받아주고(해당 프로젝트는 당장은 사실 아무거나 상관 없어 보임)

 

이제 해당 프로그램을 visual studio code로 열고 .github/workflows/push.yaml 파일을 하나 생성해주자.

 

이제 이안에 워크플로우를 작성해줄 건데 가장 먼저 이 워크플로우의 이름을 넣어주자

이 파일 내부는 key:value의 형태로 들어가며 워크플로우의 이름은 name이라는 key로 넣어주면 된다.

 

그리고 이제 이 워크플로우가 시작될 이벤트, 트리거에 대해 작성할 것인데 이벤트는 on이라는 키로 하여 값을 작성한다.

 

이제 실제 push라는 이벤트가 발생했을때 이 워크플로우가 어떤 일을 할지에 대한 내용을 넣어줘야 한다.

일이란 것은 기본적으로 job으로 구성되어 있고 다수의 job의 모임안에 job이 각각 존재하고 job은 또 다시 다수의 step으로 이뤄진다.

그래서 먼저 Job들을 가질 Jobs를 먼저 선언해주고

그리고 job을 임의의 명칭으로 지정해서 선언해주자.

그리고 이제 이 잡을 진행해줄 러너를 하나 만들어줘야 하는데 러너를 만드는 키는 runs-on이고 이 러너는 우분투에서 작업을 하기를 바라기에 값을 ubuntu-latest로 넣어주자.

 

이제 이 잡을 구성하는 step들에 대해서 선언해주자.

step은 steps로 작성하며 이 내부에는 순서대로 step을 선언해주면 된다.

먼저 step의 이름을 지정해주자.

step의 이름의 지정은 궂이 해주지 않아도 되지만 필요할떄가 있다고 생각하고 우선 만들어보자.

step의 이름은 - name을 키로 값을 넣어주면 된다.

그리고 해당 step이 진행할 일을 run이란 key로 작성해주면 된다.

여기선 echo Greeting Stranger로 해주자.

이렇게 저장해두면 push이벤트가 실행되면 job_for_push가 실행되고 첫번쨰 스탭의 1st_step인 eche Greeting Stranger가 실행되고 종료가 될것이다.

 

이제 이 파일을 github에 커밋하고 push해주고 

이제 탭중 Actions로 들어가보면

만든 워크플로우에 대한 내용이 출력된다.

나는 뭔가 조금 잘못 만들어서 커밋을 두번 다시했다.

마지막 정상적인 상태 커밋을 눌러서 들어간 후에 잡이름을 눌러서 들어가보면

이렇게 나오는데 여기서 1st_step을 눌러보면 

우리가 만들었던 echo 명령어를 통해서 Greeting Stranger가 출력된것을 볼 수 있다.

 

기존엔 우리가 아래와 같이 한줄로만 커멘드를 작성해서 실행했는데

다수의 줄을 사용하고 싶다면 | 를 사용하면 된다 

대신 명령어들은 depth를 잘 확인해줘야 할것으로 보인다.

커밋해서 push 해보고 확인해보면

이렇게 멀티로 명령어들이 실행된 것을 볼 수 있다.

 

이 워크 플로우를 활성화하지 않기 위해서는 workflows 바로 아래가 아니라 

디렉터리를 하나 더 만들어서 그 아래에 두면 워크 플로우에서 실행시키지 않을 것이다.

 

이제 위에서 봤던 명령어 하나 하나를 확인해보자.

name : push_workflows
on: push

jobs:
  job_for_push:
    runs-on: ubuntu-latest
    steps:
    - name: 1st_step
      run: echo Greeting Stranger
    - name: 2nd_step
      run : |
        echo Hi Friend!
        echo Make Friend!

 

가장 상위에 있는 name은 workflows에 대한 명칭을 지정한다.

이건 github의 actions 내역에서 해당 명칭으로 workflows를 볼 수 있다.

 

on은 어떤 이벤트가 발생했을때 해당 워크플로우가 실행될지를 설정한다.

어떤 브랜치/태그든 'git push'로 커밋(또는 태그)이 올라오면 실행된다.

 

jobs는 이제 해당 워크플로우를 이루는 작업 단위들의 집합을 정의하는 구역으로 각 job은 독립된 러너(VM/컨테이너)에서 돌아가는 하나의 실행 단위이다.

jobs 아래에는 job을 하나 선언 하기 위한 Job ID 를 선언한다.

이제 이 Job ID 아래로 Job의 내용을 선언한다.

Job은 각각 병렬로 실행되며 독립된 러너에 의해 실행되는데 러너가 어떤 환경에서 실행될지를 설정하기 위해서 runs-on이라는 명령어를 사용한다.

 

여기서는 ubuntu의 가장 마지막 버전의 환경에서 러너를 실행하도록 하게 한다는 의미이다.

위처럼 사용하면 깃허브가 잡이 시작될 때 자동으로 새 VM을 할당하고 그 위에서 잡을 돌린다.

이 VM은 잡이 끝나면 폐기되기에 사용자가 러너를 만들거나 유지보수 하지 않는다.

 

쉽게 설명하자면 잡 하나당 러너는 자동으로 생성되고 이 러너가 작업할 환경을 설정해주는 것이 runs-on이다.

물론 이것도 셀프 호스티드라는 개념이 포함되면 달라지겠지만 호스티드 러너를 사용하는(github에서 자동으로 할당하는) 경우에는 이게 맞다고 생각해도 될것으로 보인다.

 

이제 이 러너가 작업할 환경을 설정했으니 러너가 실질적으로 작업할 job의 각각의 step을 설정해줘야한다.

jobs와 같이 step도 steps라는 구역을 지정하고 

이 steps 내부에는 다수의 step을 작성해줄 수 있다.

이 step은 작성한 순서대로 작업 되며 각각의 step의 구분은 -(하이푼)으로 구분된다.

-이 작성된 부분부터 다음 -이 작성되기 이전까지가 하나의 step이라고 볼 수 있다.

각각의 step은 앞의 step이 정상적으로 종료되어야만 실행이 되고 비정상적으로 실행되면 다음 step은 실행되지 않는다.

이 step에 각각 name으로 UI/Log에서 보기 좋게 표시하기 위한 선택적으로 작성 가능한 속성이다.

각각의 step을 구분하기 위해서는 id라는 필드를 사용해서 구분이 가능하다(여기서는 사용되지 않았다.)

 

step은 보통 run(셀 명령을 실행)과 uses(액션을 호출), 두 타입 중 하나이다.

위에서는 run을 사용해서 셀 명령인 echo를 실행했다.

 

run과 uses는 동시에 사용되지 않는다.

 

여기까지가 이번에 확인했던 workflow의 명령문의 해석이다.