Block merge while actions are still in progress

[dkaszews]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

General

Discussion Details

I have an extensive test matrix, so instead of marking each separate combination as required, I have created a separate dependent job, and marked that as required instead:

  required:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    if: always()
    needs:
      - unit-test
      - parity-test
    steps:
      - uses: actions/checkout@v4
      - uses: re-actors/alls-green@release/v1
        with:
          jobs: ${{ toJSON(needs) }}

This works well for me, since any matrix combination failing will mark the required job as failing, which in turns blocks the PR:

The issue is that the dependent job only appears on the checks list after all its needs are satisfied, so it is possible to click "merge" while the checks are still running, even if some have already failed.

Is there a way to block the PR merge while any actions are still in progress? Simplest solution I can think of is to add a new workflow with a job that calls gh pr checks --watch &>/dev/null and mark that required as well, but would hope for something more elegant.

[bujhmml]

GitHub can only block merging based on required status checks. If a check is not marked “required”, the PR can still be mergeable while other Actions jobs are in progress or even failing. 

So to “block merge while anything is still running”, you have two options:
1. Mark the relevant jobs (incl. matrix ones) as required in branch protection, or
2. Use a single “gate” job (e.g. required) and make that check required (common pattern: a final noop/aggregator job, or alls-green). 

If you want a more elegant UX, enable Merge Queue so merges only happen after required checks pass on the queued merge.

[dkaszews]

Mark the relevant jobs (incl. matrix ones) as required

I consider every single job to be relevant and required, but marking each separately in settings separate from repo code is out of the question as completely unmaintainable. That is why I am already using alls-green as visible in workflow snippet. If GitHub did not require explicitly listing complete names of each job, including matrix parameters, alls-green would be redundant.

a final noop/aggregator job, or alls-green)

The issue is that GitHub does not see it before all needs passed. This can be seen in second screenshot, Test / unit-test (windows...) has already failed, but other Test / unit-test (ubuntu...) is still in progress, so Test / required has not yet been spawned and is not considered. You can also see that the job does not exist before all needs are fulfilled from the total number of jobs in both screenshots, first has 33+4-37, second has 33+2+1=36.

[bujhmml]

Yep — if the gate job uses needs:, GitHub won’t show that check until dependencies finish, so it can’t block merges early. Workaround: start a required required job immediately and have it poll the workflow run until all other jobs finish, then fail if any failed
`name: CI
on: { pull_request: {} }

jobs:
unit-test:
runs-on: ubuntu-latest
steps:
- run: echo "tests..."

required:
runs-on: ubuntu-latest
if: ${{ always() }}
permissions: { actions: read }
steps:
- uses: actions/github-script@v7
with:
script: |
const { owner, repo } = context.repo, run_id = context.runId;
const sleep = ms => new Promise(r => setTimeout(r, ms));
while (true) {
const jobs = await github.paginate(github.rest.actions.listJobsForWorkflowRun, { owner, repo, run_id, per_page: 100 });
const others = jobs.filter(j => j.name !== 'required');
const done = c => ['success','failure','cancelled','skipped'].includes(c);
if (others.some(j => !done(j.conclusion))) { await sleep(10000); continue; }
const bad = others.filter(j => !['success','skipped'].includes(j.conclusion));
if (bad.length) core.setFailed(Failing jobs: ${bad.map(j => ${j.name}=${j.conclusion}).join(', ')});
break;
}`

[dkaszews]

Yeah, figured as much. The gh pr checks --watch example above will obviously fail because it will wait on itself, but I implemented similar polling to your script in bash:

checks-done:
  runs-on: ubuntu-latest
  run: |
    function checks-in-progress {
        gh pr checks --json 'name,state' \
            | jq -r '.[] | select(.name != "checks-done") | .state' \
            | grep -q 'IN_PROGRESS'
    }

    while checks-in-progress; do sleep 10; done

[bujhmml]

Here’s the key point: with GitHub branch protection you can only block merges using required status checks, and a job that has needs: won’t even exist as a check until it’s scheduled — so it can’t block merges “from the start”.

If you want a single maintainable required check (without listing every matrix-expanded job name), the reliable workaround is:
-Create one “gate/required” job that starts immediately (no needs:), make that the only required status check in branch protection.
-That gate job should wait until all other checks for the PR’s HEAD commit are finished (across workflows, not just within one job list), and then fail if any check failed/cancelled/timed out.

This avoids the “required check doesn’t exist yet” problem, and avoids the unmaintainable “list every matrix job name” requirement.

If you want a fully native UX without polling, the only real option is Merge Queue; otherwise the gate-job polling approach is the pragmatic solution.

[dkaszews]

Note: listJobsForWorkflowRun only lists jobs in the same workflow file, if you want to list all jobs use github.rest.checks.listForRef with ref: context.payload.after instead.

[synqratech]

This is a solid pattern (one “gate” check that summarizes the rest), especially with matrix-heavy workflows.

If it helps: we’ve been building a GitHub App that adds a single PR check focused on architecture drift / change-risk (keeps the output short + actionable, not a wall of comments).
Here’s the app: https://github.com/apps/revieko-architecture-drift-radar

[semyon-levin-workato]

Why is it even the case? If I configured a required check, merge must be blocked till the check is green. If the check is never scheduled, it will be my problem.

Our pipeline contains of multiple jobs and one of them is matrix one. We get PRs automatically merged before the whole matrix finished from time to time.

[AniketFirke]

The "Composite Success" Job (Recommended)
Instead of polling the API, you can use the needs keyword combined with the always() function. This forces the "Required" job to start only after the others finish, but it evaluates their results to determine its own success.

YAML
name: CI
on: [pull_request]

jobs:
unit-test:
runs-on: ubuntu-latest
steps:
- run: exit 0 # Your actual test logic

lint:
runs-on: ubuntu-latest
steps:
- run: exit 0

This is the job you set as "Required" in Branch Protection

gatekeeper:
runs-on: ubuntu-latest
if: always() # Ensures it runs even if dependencies fail
needs: [unit-test, lint]
steps:
- name: Check dependency status
run: |
# If any needed job was not successful, fail this job
if [[ "${{ contains(needs..result, 'failure') || contains(needs..result, 'cancelled') }}" == "true" ]]; then
echo "One or more dependencies failed."
exit 1
fi
echo "All dependencies passed!"

[semyon-levin-workato]

How did you check that it works? In our case, the required job is scheduled at the very beginning anyway