Why separate jobs in Github Actions instead of adding steps?

Question

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 }}

Answer 1

In your particular example, I only know of a few benefits.

• If your deploy job fails, then it can be re-ran without doing the build step again.
• Because it's a separate job, you can ensure that the artifact is stored upstream. It also allows for the two jobs to be ran on different runners, instead of the same runner.

However, it also is designed to scale for a larger workflow where it may become important:

• You may want to build on a different GitHub runner to what you deploy on. That may be for resource reasons, compatibility reasons, etc.
• You may use environments for deploy, which will mean that the deploy secret is only available to the Deploy job.

In the future you may split these into two workflows, and this design makes that trivial. Doing so would provide you:

• Ability to trigger a deploy without a build, perhaps because you want a delay period after building, or want to rollback to a previous build