Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Needs - GitHub jobs and workflows depending on each other

name: CI

on:
  push:
  pull_request:
  workflow_dispatch:
#  schedule:
#    - cron: '42 5 * * *'

jobs:
  build:
    runs-on: ubuntu-latest
    name: Build

    steps:
    - name: Build step
      run: |
        echo This is the placeholder for the compilation step
        echo "Enable the next line if you'd like to see what happens when the job fails."
        # ls -l something_that_does_not_exist

  test:
    runs-on: ubuntu-latest
    name: Test
    needs: [build]

    steps:
    - name: Test step
      run: |
        echo This job only runs if the build job was successful

  linter:
    runs-on: ubuntu-latest
    name: Linter

    steps:
    - name: Linter step
      run: |
        echo This job is independent from the other, it can run in parallel to either the build job or the test-job

  run-generate:
    needs: [linter, test]
    uses: ./.github/workflows/generate.yaml

name: Generate

on:
  workflow_call:
  workflow_dispatch:

jobs:
  generate:
    runs-on: ubuntu-latest
    name: Generate

    steps:
    - name: Generate
      run: |
        echo This job only runs if both the linter and the test jobs were successful.
        echo This is set in the ci.yaml file calling this file

  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    needs: [generate]

    steps:
    - name: Deploy
      run: |
        echo This job only runs if the Generate job was successful.

  • repository

  • A job can declare in needs one or more other jobs to be successful before running.

  • In the CI.yaml file the test job depends on the build job. The linter job runs indpendently.

  • The needed job must be in the same workflow (in the same YAML file) so the jobs in the generate.yaml file cannot depend the jobs in the ci.yaml file.

  • However, One can make the generate.yaml workflow a reusable workflow by adding the trigger workflow_call and then make the dependencies call it.

  • In our case the ci.yaml has an extra job called run-generate that depends on both the linter and the test jobs and runs the Generate workflow if both linter and test pass.

  • Because the Generate workflow also has the workflow_dispatch trigger, one can run it from the GitHub UI in which case it will not “need” the CI job. Allowing this might or might not be a good idea.