Best practice: splitting steps in different jobs or not

Hi folks, I’m wondering whether it’s a good Idea splitting steps (all relying on ubuntu-latest) in more jobs. I need to build and deploy a project to a VPS. Job 1 builds the artifact. Job 2 copy it to a VPS. For example:

Example of separated jobs (pseudo-YAML)
name: Build & Deploy

# Run triggers
on:
  # Trigger the workflow on push to the master branch
  push:
    branches:
      - master

jobs:

  # Set the job key.
  site_build:
    # Name of the Job
    name: Build the site
    # Set the type of machine to run on
    runs-on: ubuntu-latest
    
    steps:
      # Check out a copy of this repository on the ubuntu-latest machine
      - name: Checkout code
        uses: actions/checkout@v2


      - name: Prepare the Ruby env
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.0 # Not needed with a .ruby-version file
          bundler-cache: true # runs 'bundle install' and caches installed gems automatically

      - name: Install Gems
        run: bundle install --gemfile=jekyll_site/Gemfile

      - name: Create static files
        run: BUNDLE_GEMFILE=jekyll_site/Gemfile bundle exec jekyll build

      - name: Upload the build (artifact)
        uses: actions/upload-artifact@v2
        # ...

  # Set the job key.
  deploy:
    needs: site_build
    # Name of the Job
    name: deploy to the VPS
    # Set the type of machine to run on
    runs-on: ubuntu-latest
    
    steps:
      - name: Download the build (artifact)
        uses: actions/download-artifact@v2
        with:
          name: blog-artifact
          # the new path where you want to store artifact in the ubuntu latest
          path: my_artifact

      # ... copy artifact to the VPS via SSH

PROs:

  • I separate steps from a logical perspective
  • I can easily detect in which job problems are happening

CONs:

  • I need 2 consequent separate runners
  • The artifact should be passed from Job 1 to Job 2
  • Performance

Is there any best practice or thumb rule about use cases like this? To summarize, when it is worth splitting things in more jobs?

Cheers

In a way I think you already found the question to ask as a rule of thumb: Is it worth it? Or, in more detail: Are the pros more important than the cons, and worth the effort to make the change?

For the specific case, I agree with your assessment of the pros. For the cons, I don’t think there’s going to be much of a performance difference or from using two runners, but if it’s a private repository you might get billed for a couple extra seconds for setup and artifact transfer.

If you decide to use two jobs I’d recommend limiting the retention period for the artifacts, so they don’t take up unnecessary storage space after deployment.