My Pull Request Was Green. My Tests Never Ran.

One of my stacked pull requests had a green checkmark next to it. GitHub said the branch was clean and ready. But when we checked which jobs had run, my test suite wasn’t on the list.

Here’s what gh pr checks returned for that PR:

SUCCESS Socket Security: Pull Request Alerts
SUCCESS Socket Security: Project Report

Both passing checks came from Socket Security. Neither ran my test suite. My CI workflow runs three jobs, build + vet + test, golangci-lint, and govulncheck. None of them ran on this PR, even though it looked ready to merge.

The trigger filter matches the wrong branch

The changes were stacked. PR #76 was built on top of PR #74’s branch rather than on main, because the second change depended on the first. That let work continue while the first PR was still open, but my CI configuration didn’t account for it.

My workflow file started like this:

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

The branches: filter under pull_request matches the base branch, the one you’re merging into. My stacked PR targeted fix/path-posix-promote, so the filter excluded it. The workflow’s jobs were absent from the checks list.

The push trigger was also limited to main, so pushing the feature branch didn’t run the workflow either.

The fix was deleting a single line:

   pull_request:
-    branches: [main]

The push trigger stays pinned to main to avoid duplicate runs for feature-branch pushes. The pull-request trigger now accepts any base branch.

Check which jobs passed

The other misleading signal was mergeStateStatus, which came back as CLEAN.

GitHub defines CLEAN as “Mergeable and passing commit status.” That describes the merge state; it doesn’t list which jobs ran. In this case, the passing checks came from Socket Security while the test workflow was missing.

Before merging, I want build + vet + test, golangci-lint, and govulncheck present and successful for the revision being merged. Counting green rows isn’t enough if they’re the wrong jobs.

Getting CI running

After the workflow fix merged, the feature change landed as a new PR based on main. That PR is #79, and gh pr checks on it returns:

SUCCESS govulncheck
SUCCESS golangci-lint
SUCCESS build + vet + test
SUCCESS Socket Security: Pull Request Alerts
SUCCESS Socket Security: Project Report

Five checks instead of two, including all three CI jobs. By then, both the workflow and the base branch had changed, so this wasn’t a test of the filter change in isolation. It did confirm that CI ran on the replacement PR.

There was a branch cleanup problem along the way. After the lower branch was merged and deleted, the PR stacked on top ended up closed. The recovery used here was to rebase onto main with git rebase --onto and open #79 as a fresh PR.

I’ll check the dependent PR’s target and state before deleting a branch beneath it, including whether GitHub has retargeted it.

Run gh pr checks <PR-number> on a recent PR and look for the jobs you expect. Check their names and results. I want to know that my tests passed before a merge, and that starts with making sure they ran.

Sources

• Events that trigger workflows — GitHub’s reference for pull_request filters, including how branches: is evaluated
• MergeStateStatus enum — the GraphQL definition of CLEAN
• gh pr checks — the CLI command used for every check listing in this post
• dotfiles-manager PR #79 — the re-landed PR with all five checks, and the one-line workflow fix

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].