이번 글에서는 저번 글에서 더 나아가서, 좀 더 상세하게 Github action이 어떻게 이루어져있는지 살펴보도록하겠다!
레츠기릿 🔥
이 글은 공식문서 : Learn GitHub Actions를 보면서 공부, 실습한 글이다.
하나의 Github action은 이러한 요소들로 이루어져있다고 한다.
그렇다면, 하나 하나 자세히 살펴보자!
워크플로우는 여러 Job으로 이루어진 하나의 프로세스이다. 저번 글에서 yml파일을 하나 만들었는데, 이 파일 하나가 하나의 워크플로우를 의미하는 것이다.
예를 들어서, 테스트 & 빌드
워크플로우, 배포
워크플로우를 만들어서 순서대로 실행시킬 수 있는 것이다.
이벤트는 레포지토리에서 발생하는 다양한 사건(?)을 이야기한다.
PR이 들어왔거나, Issue가 생성됐거나 누군가 커밋을 한 것과 같은 레포지토리에서 일어하는 모든일을 이벤트라고 부르는 것이다.
당연히 이러한 이벤트들이 발생했을 때, 특정 워크플로우가 실행되게 할 수 있다.
예를 들자면, production
이라는 브랜치에 코드 push가 발생하면 production
브랜치의 코드를 배포하는 워크플로우를 실행시킬 수 있을 것이다!
Job은 워크플로우에 정의된 하나 하나의 스텝들이다.
Shell script를 실행하는 Job일 수도 있고, 특정 Action
을 실행하는 Job일 수도 있을 것이다.
다른 개념들보다는 조금 헷갈릴 수 있는 개념인 것 같다.
공식문서의 설명을 그대로 먼저 이야기하자면, Action
은 GitHub Actions
플랫폼에 맞게 만들어진 애플리케이션이라고 한다.
음~~ 조금 쉽게 예시를 든다면, 크롬과 크롬 확장 프로그램의 관계와 비슷하다고 할 수 있을 것 같다.
Action은 내가 직접 만들수도 있고, Marketplace에서 이미 만들어진 것을 찾아서 쓸 수도 있다.
내가 직접 만든다면, 이런 것들을 만들 수 있을 것이다.
그리고 마켓플레이스에 들어가보면 사실 어지간한 것은 다 있는 것 같다 ㅎㅎ
예를 들면, Gradle프로젝트 배포하기
액션도 있고, Gradle 프로젝트를 빌드한 패키지 배포하기
액션도 있다.
사실 Github action이 어떻게 동작하는 지 가장 궁금했던 부분이 바로 이 Runners가 하는 역할이다.
지금까지의 설명을 읽어보면, Github Action은 컴퓨터에서 돌아가는 프로그램과 같은 것인데, "컴퓨터"가 어떻게 동작한다는 이야기가 없었다.
Runners가 바로 그 "컴퓨터"이다. ㅎㅎ
Ubuntu, window, mac 중에서 os를 선택할 수 있고 선택한 os에 맞게 돌아가는 가상 머신 또는 가상 서버라고 한다.
내가 구성한 워크플로우가 실제로 실행되는 영역이 바로 Runner인 것이다 👍
정말... 이런 거 만드는 사람들은 참... 대단한 것 같다 🙏
자! 여기까지 Github action이 어떤 요소들로 구성이 되는 지 알아봤다.
이제 어떻게 돌아가는지는 대충 알겠고 한번 지대로 돌려보고 싶은 생각이 든다 ㅋㅋ
그 전에 내가 구현할 워크플로우를 yml파일에 작성해야하는데, 워크플로우를 만들기 위한 yml문법을 알아야한다.
다음 글에서는 제대로된 워크플로우 작성을 위한 yml 문법들을 알아보도록 하겠다!