re-runre-run은 같은 커밋(SHA), 같은 워크플로우 정의로 실패, 취소(혹은 조건에 의해 스킵)된 잡을 다시 돌려보는 것이다.워크플로우를 새로 돌리는게 아니라 같은 Run ID로 시도 번호만 증가하게 된다. 먼저 re-run하기 위해서 워크플로우를 하나 생성해보자.그리고 push 이벤트에 반응 하는 workflow를 만들어주자.이제 job을 만들텐데 job은 현재 워크플로우가 보고 있는 커밋을 기준으로 데이터를 가져오는 checkout을 사용해주도록 하자이때는 run이 아니라 uses를 사용하고 use에 actions/checkout@v4를 사용한다.이건 내 저장소의 파일들을 러너가 활동하는 환경(빌드 머신)으로 내려받는다라는 명령어이다.깃허브 액션이 실행될 때 러너가 활동하는 환경은 아예 아..

workflow를 실행하다 보면 job들은 모두 병렬로 돌아간다고 얘기했던 적이 있었다.근데 job 중에서는 서로 의존 관계를 가지는 경우들이 존재한다.예를 들면 build → test → deploy 와 같이 서로 의존 관계를 가지는 형태의 job이 생성될 수 있는데 job이 병렬로 실행되면 순서의 보장이 되지 않고, 앞 단계가 실패하더라도 다른 단계들이 병렬로 시작되어 러너와 시간의 낭비가 생긴다.또한 아티팩트(빌드 산출물)이 먼저 만들어져야 하는데 다른 잡이 먼저 돌아 건너 뛰는 상황이 발생하기도 한다. 이때 이를 해결해 줄 수 있는데 needs이다 needsneeds는 병렬로 수행되는 job의 실행 순서를 명시해서 그래프로 묶어 선행 성공 후에만 후행 실행하고 실패하면 기본적으로 스킵한다.이를 통..

여러 이벤트에서 하나의 workflow를 불러야하는 경우가 있을 수도 있는데 이런 경우도 등록이 가능하다서로 크게 특별할 것은 없고 등록할때 이벤트를 다수 설정해주면 된다 . 만들어 보면서 확인해보자. 먼저 파일을 하나 만들어주고이름을 먼저 작성해주자.이제 on의 하위로 이벤트를 등록하는데 그냥 간단하게 다수의 이벤트를 지정하면 된다.이렇게 해두고 각 이벤트 마다의 job을 분기로 나누면 각 이벤트 마다 실행할 job을 나눌 수도 있다. job을 한번 만들어보자면이렇게 분기를 쳐서 만들 수 있다. 한번 commit & push 하고 이제 먼저 issue와 workflow_dispatcher 부터 확인해보자.먼저 issue에 글을 달고 실행 되었고 workflow-dispatcher로 실행해보면실행 되었고..

workflow dispatch는 사용자가 직접 수동으로 worflow를 실행할 수 있는 수동 실행 트리거이다.추후에 확인하겠지만 레포지토리의 Action탭에서 Run workflow라는 버튼이 생겨 직접 실행하거나 API나 CLI로 실행할 수 있게 된다. 보통 즉시 수동으로 배포 혹은 롤백 해야하거나, 핫픽스 , 임시 스크립트 실행, schedule 지연시 수동 보정등의 작업을 위해서 사용된다. 기본적으로 레포지토리에 write 이상의 권한이 존재하는 경우의 사용자만 실행이 가능하고 조직 정책 및 규칙에 따라서 추가로 승인을 해줘야 할 수 도 있다. 또한 실행 시 사용자의 입력을 받아 job에서 활용하는게 가능하다.입력값은 문자열로 들어가며 github.event.inputs.으로 접근이 가능하다.또한..

schedule event의 경우는 POSIX cron 문법으로 특정 시간/주기에 워크플로우를 자동으로 실행하게 하는 이벤트이다.schedule의 등록은 와 같이 on의 하위로 schedule로 이벤트를 걸고 여기에 - cron으로 시간을 지정한다.각 시간은 와 같이 자리마다 분, 시간, 날짜, 월, 주 같은 기준이 들어가며 *이 들어가면 매 분, 매 시간 등등에 이벤트가 발생하게 된다.이는 이렇게 각각의 operator에 대해서 작성되어 있는 기준에 따른다. 그리고 schedule 이벤트의 경우는 default branch에 workflow가 존재하는 경우에만 workflow를 실행한다. 그리고 이 스케쥴에 대한 잡은 씹히는 경우가 종종 발생하는 것 같다.Github action의 schedule은 ..

이슈와 Pull Request 모두 Comment를 추가할 수 있는데 둘다 모두 이슈형 리소스이기 때문에 두 곳에서 달린 일반 댓글들이 모두 issue_comment이벤트로 들어오게 된다. 이때 issue_comment의 경우는 아래 세개 Activity types에 대해서 트리거 되고 issue와 동일하게 default branch에 workflow가 있을 경우에만 workflow가 실행된다. 이 issue_comment의 경우는 사용방법이 조금 다른데 먼저 기본적으로 name과 이벤트를 등록해보자면여기 까지는 그냥 아는 것과 같이 작성을 해도 무방하다 이제 jobs 부분이 조금 다른데 말했다 싶이 pull request의 comment인지 issue에 대한 comment인지를 분기처리를 해줘야만 각..