0
votes

In this Github Actions deployment script example, the author separate the build and deployment into distinct jobs.
Given that:

  • these jobs run sequentially (needs: build)
  • and on the same runner (runs-on: ubuntu-latest)

What is the advantage of separating into two jobs instead of simply inserting a build step inside the deploy job?

Here is the example:

name: Build and Deploy
on:
  push:
    branches:
      - master

jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@master
      - name: Install Dependencies
        run: npm install
      - name: Build
        run: npm run build-prod
      - name: Archive Production Artifact
        uses: actions/upload-artifact@master
        with:
          name: dist
          path: dist
  deploy:
    name: Deploy
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@master
      - name: Download Artifact
        uses: actions/download-artifact@master
        with:
          name: dist
          path: dist
      - name: Deploy to Firebase
        uses: w9jds/firebase-action@master
        with:
          args: deploy --only hosting
        env:
          FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}

1
I guess the main reason is because you may often need to build / upload various artifacts in parallel with different jobs (top optimize the workflow run execution time), and then use all of them in one last job (deploy). But when there is just one artifact, it could, as you said, be done on the same job. - GuiFalourd

1 Answers

0
votes

For me the most important reson id CD part. When you want to deploy to enviroments you may sometine want to have control over it. And thus may vary depdends on the env. Using mutliple jobs you can have one job = envionment which is not possible if you put everytning into one job, as then you have Dev or Test env but not both.

Please check what environments gives you here.

Another useful thing is retry. You may want to retry failing phase and if this is deployment there is no point of retrying the whole build process.