fix(safety): revert target_url additions that broke ci-safety dogfood#76
Merged
Conversation
DIAGNOSTIC PR — not intended for permanent merge unless we confirm it fixes the bug AND decide to live with the unclickable gate status. Background: ci-safety.yml's dogfood (`safety / scan` job) has been silently broken since 2026-05-28 05:21 — every PR produces a 0-job phantom startup_failure. The complete file-level diff between the last working state (HEAD a8655fe at 2026-05-26 06:19) and the first broken state (HEAD 01d9280 at 2026-05-28 05:21) is exactly these 9 lines: three `-f target_url=...` arguments added to three `gh api .../statuses/${HEAD_SHA}` calls inside dep-safety.yml's run-blocks. This PR reverts those 3 lines (plus the 3 backslash-continuation modifications they required on the preceding `-f description=` lines) to test whether they are causally involved in the phantom-failure behavior. Possible outcomes when this lands on a PR: 1. Phantom failures STOP and ci-safety's `safety / scan` job runs again → the target_url expressions are causally involved. We then need to either find another way to make the gate clickable or accept the unclickable status. 2. Phantoms persist → the target_url changes are NOT involved; the regression must be a coincident GitHub-side platform change. Support ticket is the only path remaining. Refs phantom runs: - 26556360487 (first phantom, our feature branch push 2026-05-28 05:21) - 26556546736 (PR #71 merge) - 26556922328 (PR #72 feature branch) - 26557123379 (PR #73 feature branch) - 26557436258 (PR #74 merge) - 26558104480 (PR #75 merge — new workflow_id 284671829, still broken) The diagnostic itself reverts to the working file-content state for just this file; everything else (file rename to dep-safety.yml, doc header from #73, name="Dependency Safety (reusable)" from #74) is left intact since we want to test the target_url-specific hypothesis in isolation.
j7an
changed the title
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Revert the three
-f target_url=...arguments added by #71 togh api .../statuses/${HEAD_SHA}calls indep-safety.yml. The expressions${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}inside aworkflow_call-only workflow'srun:block cause GitHub Actions' scheduler to abort caller invocations before any job launches — a 0-job startup_failure with no logs.How we got here
PR #71 added
target_urlto make thedependency-safety / gatePR status row clickable. The diff was 9 lines, lint passed, CI was green. But starting at the moment that branch was first pushed (2026-05-28 05:21),ci-safety.yml's dogfood stopped running. Every PR since produced a phantom 0-job failure on bothci-safety.yml(the caller) anddep-safety.yml(the called workflow). PRs #72-#75 attempted to fix this via name-collision repair (#72), file-touch refreshes (#73),name:value changes (#74), and finally a file rename to force fresh workflow_id registration (#75). None worked — the newdep-safety.ymlworkflow_id (284671829) registered with the same broken state as its predecessor (281959865).This PR localizes the regression by reverting just the 9 lines from #71 while keeping every other change (file rename,
name:value, doc header) intact. The dogfood ran successfully on this PR's first push (safety / scanpass, 10s — see theCI Safetycheck on this PR). That's the first real ci-safety job since 2026-05-28.The
target_urlexpressions are the cause. The 9-line revert is the fix.Trade-off
The
dependency-safety / gatePR status row goes back to being unclickable. That's the pre-#71 state — accepted as the price of a working dogfood. A follow-up PR will try a workaround using shell env vars (${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}) instead of${{ }}expressions; if GitHub's scheduler quirk is specifically about template-expression analysis inrun:blocks, the env-var form may sidestep it and restore clickability without re-breaking the dogfood. Filed separately so this fix can merge immediately.What's not changed
dep-safety.yml(rename from fix(safety): rename dependency-safety.yml to dep-safety.yml #75 retained)name:stillDependency Safety (reusable)(from fix(safety): rename workflow name to force registry refresh #74)ci-safety.ymllocaluses:path (from fix(safety): rename dependency-safety.yml to dep-safety.yml #75), bats test path references (from fix(safety): rename dependency-safety.yml to dep-safety.yml #75) all intactRefs
Phantom run IDs across the affected merges:
26556360487,26556546736,26556922328,26557123379,26557436258,26558104480.Workflow registrations after this PR merges:
281950779—ci-safety.yml, name "CI Safety" ✅284671829—dep-safety.yml, name still falls back to path (zombie of the bug, but no longer affects dogfood once these lines are gone) ❓281959865— olddependency-safety.yml, zombie at the rename's previous path ❓The two zombie registrations no longer match any file on
main, so they should be inert. We can decide whether to ask GitHub to clean them up later.