On a push to development, quality.yml deliberately passes an EMPTY base and lets the pinned package auto-detect (origin/HEAD → origin/development → origin/main → origin/master). In a repo where that chain lands on the branch being pushed, the base IS HEAD, and v1.5.0 correctly refuses:
[hydra-gates] Base ref: origin/development (auto-detected) = 9db0dc593
[hydra-gates] WARNING: the base ref resolves to the SAME COMMIT as HEAD.
[hydra-gates] ERROR: diff base "origin/development" IS HEAD (9db0dc593...).
[hydra-gates] would report PASS over an empty file set. Refusing.
[hydra-gates] RESULT: COULD NOT RUN (exit 99). This is a configuration error, not a green.
[hydra-gates] GATES THAT DID NOT RUN: 1 2 3 ... 64
The refusal is right. Reporting PASS over an empty diff is the false green the whole coverage accounting exists to prevent. The bug is that the caller puts the package in that position on every mainline push.
Not universal — it depends where the chain lands
| repo |
default branch |
push to development |
| openregister |
main |
exit 99, 64 gates did not run |
| hermiq |
development |
gates ran, real verdict |
So some repos gate their mainline pushes and some gate nothing, with no signal distinguishing the two beyond reading the log. Seen while sweeping hydra-gates-ref to v1.5.0 across 11 repos (needed because the floating workflow calls check_spec_anchors.py, check_form_labels.py and check_license_triangle.py by path — the #168 failure mode again).
Suggested
quality.yml already special-cases the PR event to compute a real base. Give the push event the same treatment rather than an empty string: on a mainline push the honest base is the previous commit range GitHub already supplies (github.event.before), or the gates should run unscoped — which is what the package itself suggests ("Run WITHOUT --scope-to-diff on a mainline branch").
Either is a decision about what a mainline run is FOR: re-gating the whole tree, or gating what that push added. Right now it is neither, and the job reports nothing while looking like a failure about the code.
On a push to
development,quality.ymldeliberately passes an EMPTY base and lets the pinned package auto-detect (origin/HEAD → origin/development → origin/main → origin/master). In a repo where that chain lands on the branch being pushed, the base IS HEAD, and v1.5.0 correctly refuses:The refusal is right. Reporting PASS over an empty diff is the false green the whole coverage accounting exists to prevent. The bug is that the caller puts the package in that position on every mainline push.
Not universal — it depends where the chain lands
developmentmaindevelopmentSo some repos gate their mainline pushes and some gate nothing, with no signal distinguishing the two beyond reading the log. Seen while sweeping
hydra-gates-refto v1.5.0 across 11 repos (needed because the floating workflow callscheck_spec_anchors.py,check_form_labels.pyandcheck_license_triangle.pyby path — the #168 failure mode again).Suggested
quality.ymlalready special-cases the PR event to compute a real base. Give the push event the same treatment rather than an empty string: on a mainline push the honest base is the previous commit range GitHub already supplies (github.event.before), or the gates should run unscoped — which is what the package itself suggests ("Run WITHOUT --scope-to-diff on a mainline branch").Either is a decision about what a mainline run is FOR: re-gating the whole tree, or gating what that push added. Right now it is neither, and the job reports nothing while looking like a failure about the code.