CI/CD가 많은데 ACTION의 장점은
GITHUB와의 통합성

대부분은 CI/CD툴은 CI만을 위한 툴이 됨
github action을 이용하면 되게 많은 것들을 해결할 수 있음

장점은 커뮤니티가 매우 큼
쉽고, 많은 것들을 사용할 수 있음. 환경에 거의 자유로움
로깅이 잘 되어 있음 찾고, 다운로드가 되고, 특정 줄을 링크할 수도 있고, 이런 여러가지 장점이 있음

easy to write easy to shae
yaml 파일 기본임
ci, cd, container, 코드... 같은 것들을 다 관리해 줌

Events

트리거 역할을 함.
on: 부분에 해당함. push, pull_request, 스케쥴, 워크플로우 디스패치(api, thirdparty),manual trigger

Workflows

자동화 구조, 할 일들
pipeline과 비슷함 (jenkins)
yaml 로 설명 하고, 원하는 게 뭔지 편하게 나옴.
matrix로 버전 설정, os 버전 같은 것들이 다 가능함
심지어 여러 버전에 대해서 테스트를 다 할 수도 있음
단순히 node version을 3개 설정하고, os를 3개 설정하면 9번 테스트를 다 해줌
너무너무 좋은 기능이 많음

.github/workflows 폴더 안에 있어야 github action을 사용할 수 있음
.yml파일을 그 안에 넣으면 됨

step을 잡는다.
그냥 바로 shell script를 사용할 수도, 직접 하나하나 다 이미 있는 액션을 사용할 수도 있음

버전 설정은 좀 잘 하면 좋다. 그래야 버그가 안 터질 수 있음. npm ci

action은 vm에서 돌아감. 도커는 오직 linux에서만 돌아간다는 거 기억.

Actions

골에 관련 됨
reusable units of code test코드 같은 느낌임. action.yml파일로 메타데이터로 액션을 정의 해 줘야 함.
어떤js로 바꿀 수 있다면 .net같은 것도 알아서 js로 바꿔서 알아서 처리 해줌.

action을 그냥 있는 거를 쓸 수도 있고, 직접 짤 ㅅ도 있다는 것

사진에 있는 uses: actions/setup-node@v1같은 부분이 다른 사람의 action을 가져와서 그걸 실행한다는
것
action을 공유하려면 public이어야 함.
type of actions

js action은 되게 직관적으로 값 싸게, 스타트업 시간이 짧기에 나쁘지 않은 선택지. 원할 때마다 바로 찾아서 열면 끝
container action은 느림. docker 부분을 다 가져와야기에 시작 부분은 조금 느림.

수많은 회사들이 다 같이 action들을 만들고 있음. public의 장점

예제 action은 ci/cd와 관련되는 것이 아닌, 그냥 코드가 적절한지 issue is stale한지 확인 close stale action은 issue를 받고, 바로 닫아버리는 과정이 있음. schedule 관리에 좋음. 그냥 github issue 관리 느낌 close stale issue

create javascript action
이라고 하는 action 시작 코드 자동화 하는 nest cli느낌

action 부분에는 2가지 방법이 있음
monolithic action
step에 순서대로 action을 만듦. compact 코드라는 관점에서는 나쁘지 않은 시간이지만, 전부를 다 해야하기에 코드가 역할이 너무 많아짐. 디버그 과정이 지저분해짐 수정 과정도 너무너무 어려워짐
심지어 전 꺼에 의존한다면...? 최악

chiaining 을 한다.
1은 테스트, 1은 api, 1은 배포 같은 chaining을 하는 방식을 사용한다. 단순하게 step에 다 묶는 것이 아닌. 파일 하나에 담는 것은 같지만, 다른 "이름"을 가진 action으로 분리해서 관리한다.

action은 starter workflow라는 것을 통해서 cli로 기본 작성을 짜줄 수 있음.

from
출처