Skip to content
You're viewing an older version of this GitHub Action. Do you want to see the latest version instead?
check-circle

GitHub Action

wait-other-jobs

v1.2.1

wait-other-jobs

check-circle

wait-other-jobs

Waits for all or specific other jobs, even if they are defined in other workflows

Installation

Copy and paste the following snippet into your .yml file.

 
              
- name: wait-other-jobs

              
  uses: kachick/[email protected]
Learn more about this action in kachick/wait-other-jobs

Choose a version

wait-other-jobs

CI Itself

Overview

This action waits all GitHub Action jobs even if they are running in other workflows.
When some jobs failed, this action exit with NON 0 value. Otherwise exit with 0.

I mainly use this action for below use-case when they should run after multiple CI workflows

Success pattern with default inputs, it behaves as Exponential Backoff And Jitter.

Example of actual log - success in default

Error pattern with specified equal_intervals and attempt-limits.

Example of actual log - error in equal_intervals_and_attempt-limits

Usage

Just requires github-token for minimum configuration.
I recommend to use timeout-minutes together with.

jobs:
  with-waiting:
    runs-on: ubuntu-latest
    steps:
      - name: Wait other jobs are passed or failed
        uses: kachick/[email protected]
        timeout-minutes: 15
        with:
          github-token: "${{ secrets.GITHUB_TOKEN }}"

You can adjust status polling interval and turns early-exit as below.

with:
  github-token: "${{ secrets.GITHUB_TOKEN }}"
  min-interval-seconds: '300' # default '30'
  retry-method: 'equal_intervals' # default 'exponential_backoff'
  early-exit: 'false' # default 'true'

Full list of the changeable parameters

NAME DESCRIPTION TYPE REQUIRED DEFAULT OPTIONS
github-token Basically GITHUB_TOKEN string true N/A
min-interval-seconds Wait this interval or the multiplied value (and jitter) for next polling number false 30
retry-method How to wait for next polling string false exponential_backoff exponential_backoff, equal_intervals
early-exit Stop rest pollings if faced at least 1 bad condition bool false true
attempt-limits Stop rest pollings after this attempts even if other jobs are not yet completed number false 1000
dry-run Avoid http requests for tests bool false false

Below is a typical usecase. Assume test jobs defined in another workflow.

name: Merge bot PR after CI
on: pull_request

permissions:
  contents: write
  pull-requests: write
  # checks: read # For private repositories
  # actions: read # For private repositories

jobs:
  dependabot:
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - name: Dependabot metadata
        id: metadata
        uses: dependabot/[email protected]
        with:
          github-token: '${{ secrets.GITHUB_TOKEN }}'
      - uses: actions/checkout@v3
      - name: Wait other jobs
        if: ${{steps.metadata.outputs.update-type != 'version-update:semver-major'}}
        uses: kachick/[email protected]
        timeout-minutes: 10
        with:
          github-token: '${{ secrets.GITHUB_TOKEN }}'
      - name: Approve and merge
        if: ${{steps.metadata.outputs.update-type != 'version-update:semver-major'}}
        run: gh pr review --approve "$PR_URL" && gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

  renovate:
    runs-on: ubuntu-latest
    if: ${{ github.actor == 'renovate[bot]' }}
    steps:
      - uses: actions/checkout@v3
      - name: Wait other jobs
        uses: kachick/[email protected]
        timeout-minutes: 10
        with:
          github-token: '${{ secrets.GITHUB_TOKEN }}'
      - name: Approve and merge
        run: gh pr review --approve "$PR_URL" && gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

Limitations

Judge OK or Bad with the checkRun state at the moment.
When some jobs will be triggerred after this action with needs: [distant-first], it might be unaccurate. (I didn't faced yet)

GITHUB_TOKEN vs PAT

This action just requires following GITHUB_TOKEN permissions. Needless annoying setup and needless unsecure around PAT.

permissions:
  contents: write
  checks: read
  actions: read

I used a way to comment @dependabot merge in past. This is simple to ensure CI passed.
However it requires PAT(Personal Access Token).
PAT could't be reduced the permission scope to repository.
And it requires annoy steps to generate, sets and maintains tokens even if refined with beta version.

This action provides another way. It checks other workflows/jobs statuses in actions with GITHUB_TOKEN.

Cons

Why avoid automerge and platformAutomerge provided by renovate official?

automerge is slow. platformAutomerge requires many repository settings.

When you feel no issues around that, do not need to migrate to this action.
It requires many changes in repository settings around Allow auto-merge, Require status checks to pass before merging and specify the checked workflow name.
Especially specifying mandatory CI names in all personal repositories are annoy task to me.
If we are talking only about organizations, hashicorp/terraform might resolve it easier.

License

The scripts and documentation in this project are released under the MIT License