workflow

Step과 Job의 차이점 Step은 무조건 순차적으로 실행되는 반면, Job은 병렬적으로 실행될 수도 있고 순서대로 실행될 수도 있다. 이 말은 Step에서 실패를 제어하기 위해 사용했던 전제인 "먼저 실행된 Step은 이후 Step 시작 전에 끝난다"가 더이상 유효하지 않다는 뜻이다. 따라서 이 전제를 맞추기 위해 추가적인 설정을 해주어야 한다. 병렬적인 Job 간의 실패 제어 일단, 병렬적인 Job A와 Job B가 있다고 해보자. B가 A의 실패를 제어하는 것은 불가능하다. 이유는 B는 A에 대한 정보가 없기 때문이다. 하나의 Job이 다른 Job에 대한 정보를 알기 위해서는 needs Context를 사용해야 하는데, 병렬적인 Job 간에는 needs에 다른 Job의 정보가 없다. 공식 문서에는..

Step 실패 시 흐름 제어 이전 글에서 if와 failure() 을 조합해 Step 실패 시 실행되는 Step을 정의해보았다. 그렇다면 만약 여러 Step이 있고 특정 Step이 fail 되었을 때만 수행되어야 하는 Step이 있으면 어떻게 해야할까? 바로 if 문에 step failure을 체크하기 위한 코드를 추가하는 것이다. 이를 위해 다른 step의 어떤 상태 값에 접근할 수 있는지 Context를 확인해보자. 특정 step이 fail 되었는지 체크하기 위한 Context steps Context 에서는 steps..outcome 를 통해 step 실행 결과에 대한 상태 값을 제공한다. 속성 이름 Type Description steps..outcome string continue-on-erro..

이전 시간까지의 내용 이전 시간에서 우리는 test를 돌리는 Job과 build를 실행하는 Job을 순서대로 실행하는 방법에 대해 알아보았다. Test를 실행하는 Job은 다음과 같았고, test: runs-on: ubuntu-latest steps: - name: Check out Repository uses: actions/checkout@v3 - name: set up JDK 11 uses: actions/setup-java@v3 with: java-version: '11' distribution: 'temurin' cache: gradle - name: Grant execute permission for gradlew run: chmod +x gradlew - name: Test with Grad..

Workflow가 Cancel 되는 경우 Job이 실패하는 경우 Job이 Fail 되면 Workflow는 Cancel 된다. Job은 하나 이상의 Step이 Fail되면 Job은 자동으로 Fail된다. 또한 해당 Job을 필요로 하는 Job 또한 모두 실패한다. 직접 취소를 시키는 경우 Cancel workflow 버튼을 눌러 직접 Workflow를 취소 할 수 있다. Workflow가 취소 되었을 때 다시 실행하기 위에서 Cancel workflow 버튼을 누르면 아래와 같은 취소 화면이 뜬다. 여기서 Re-run jobs 를 누르면 실패한 Job을 다시 실행하거나 Workflow 자체를 처음부터 다시 실행 할 수 있다. Re-run failed jobs : 실패한 Job을 다시 실행 Re-run fa..

이전까지 내용 요약 이전까지 name:을 사용해 Work Flow의 이름을 정하고, on:을 사용해 Work Flow의 Trigger Event를 설정했으며, jobs: 에 first-job이라 불리는 첫 Job을 설정하고 이 Job의 runs-on: 에 ubuntu-latest를 설정해 GitHub Action에서 제공하는 가장 최신 우분투 버전에서 실행되도록 만들었다. # WorkFlow의 이름 설정 name: First Action # on: Work Flow가 언제 실행되어야 하는지 설정 # workflow_dispatch : 유저가 직접 실행하도록 설정하는 옵션 on: workflow_dispatch #jobs: workflow에 포함된 job들을 정의 jobs: #[Job 이름]: 으로 Job..