fix(ci): rename ci-safety workflow to break name collision#72
Merged
Conversation
Both ci-safety.yml and the reusable dependency-safety.yml declared name: Dependency Safety. GitHub registered ci-safety.yml first under that name and fell back to registering dependency-safety.yml under its file path as the display name. The unresolvable name caused the check-suite scheduler to emit phantom startup-failure runs (0 jobs, no logs) on pushes that touch dependency-safety.yml — observed on the fix/gate-status-target-url branch push and on the merge of #71. Renaming ci-safety.yml's name: to "CI Safety" disambiguates the two workflows so dependency-safety.yml can register under its proper name. The reusable workflow's display name is unchanged, so consumer repos see no difference. Cosmetic-only on this repo's Actions tab: the dogfood workflow row will now read "CI Safety" instead of "Dependency Safety". Refs run https://github.com/j7an/shared-workflows/actions/runs/26556546736 (the phantom failure on the post-merge push to main).
5 tasks
j7an
added a commit
that referenced
this pull request
May 28, 2026
Document that this workflow is consumed both externally (via the
public uses: reference) and internally by ci-safety.yml — and that
ci-safety.yml is intentionally registered as "CI Safety" to keep
this workflow's display name "Dependency Safety" unambiguous in
the Actions UI.
Side effect: this commit causes GitHub to re-register the workflow,
refreshing its display name from the stale path-fallback value
(".github/workflows/dependency-safety.yml") to "Dependency Safety".
That stale value is the residue of the original name collision with
ci-safety.yml (resolved in #72) and was causing GitHub's scheduler
to emit phantom startup-failure runs on every push that modifies
this file. Disable/enable via the API did not refresh the
registration; only a file-level change does.
Refs runs:
- https://github.com/j7an/shared-workflows/actions/runs/26556546736
- https://github.com/j7an/shared-workflows/actions/runs/26556959117
3 tasks
j7an
added a commit
that referenced
this pull request
May 28, 2026
Diagnostic PR. Previous attempts to refresh dependency-safety.yml's registered display name failed: - #72 (rename ci-safety to break collision): didn't refresh this workflow's record (only ci-safety's record refreshed). - API disable/enable: state cycled but name stayed at the path fallback. - #73 (touch the file via comment header): updated_at advanced but name field still stuck at ".github/workflows/dependency-safety.yml". Hypothesis: GitHub re-resolves the name field only when the value of the YAML `name:` key itself changes — not on file-content changes or API-level state cycles. This PR changes the name from "Dependency Safety" to "Dependency Safety (reusable)" to force resolution. Post-merge verification: gh api repos/.../actions/workflows/281959865 --jq '.name' If that returns "Dependency Safety (reusable)", the resolver did run and we can decide whether to rename back. If it stays at the path string, this is a GitHub-side bug and we escalate via support ticket. The display name is cosmetic: it appears in consumers' Actions UIs as the row label, but does not affect the `uses:` path. Consumer repos will see the label "Dependency Safety (reusable)" until/unless we rename back. Refs: phantom runs blocking ci-safety dogfood since 2026-05-28.
5 tasks
j7an
added a commit
that referenced
this pull request
May 28, 2026
Force a fresh GitHub Actions workflow registration to recover from the stuck path-as-name fallback that's been blocking ci-safety dogfood since 2026-05-28. PRs #72-#74 confirmed that GitHub's registry won't refresh the existing workflow's name field on any combination of file edit, API disable/enable, or `name:` value change. A new file path forces registration as a new workflow_id with fresh name resolution. Internal-only change. Public `@v3` consumers continue to pin to `uses: j7an/shared-workflows/.github/workflows/dependency-safety.yml@v3`, which resolves against the existing v3.x.y tag where the file still exists under the old name. No release is cut from this commit; main diverges from the v3 floating tag until/unless we decide to release. Files updated: - .github/workflows/dependency-safety.yml → dep-safety.yml (git mv) - .github/workflows/ci-safety.yml: local `uses:` path - scripts/check-inline-sync.sh: INLINE_PAIRS entries - .claude/CLAUDE.md: file-path references in repo docs Not touched (per scope discipline): - Status check context `dependency-safety / gate` - Label names `dependency-safety-error` - HTML scan-comment marker - Public README examples (still document v3 with old filename) - In-file prose comments inside the workflow Refs phantom runs: 26556546736, 26556959117, 26557110156, 26557123379, 26557302648, 26557436258, 26557436258. Verification post-merge: gh api repos/j7an/shared-workflows/actions/workflows --jq \ '.workflows[] | select(.path | endswith("dep-safety.yml")) | {id, name}'
j7an
added a commit
that referenced
this pull request
May 28, 2026
Force a fresh GitHub Actions workflow registration to recover from the stuck path-as-name fallback that's been blocking ci-safety dogfood since 2026-05-28. PRs #72-#74 confirmed that GitHub's registry won't refresh the existing workflow's name field on any combination of file edit, API disable/enable, or `name:` value change. A new file path forces registration as a new workflow_id with fresh name resolution. Internal-only change. Public `@v3` consumers continue to pin to `uses: j7an/shared-workflows/.github/workflows/dependency-safety.yml@v3`, which resolves against the existing v3.x.y tag where the file still exists under the old name. No release is cut from this commit; main diverges from the v3 floating tag until/unless we decide to release. Files updated: - .github/workflows/dependency-safety.yml → dep-safety.yml (git mv) - .github/workflows/ci-safety.yml: local `uses:` path - scripts/check-inline-sync.sh: INLINE_PAIRS entries - .claude/CLAUDE.md: file-path references in repo docs Not touched (per scope discipline): - Status check context `dependency-safety / gate` - Label names `dependency-safety-error` - HTML scan-comment marker - Public README examples (still document v3 with old filename) - In-file prose comments inside the workflow Refs phantom runs: 26556546736, 26556959117, 26557110156, 26557123379, 26557302648, 26557436258, 26557436258. Verification post-merge: gh api repos/j7an/shared-workflows/actions/workflows --jq \ '.workflows[] | select(.path | endswith("dep-safety.yml")) | {id, name}'
j7an
added a commit
that referenced
this pull request
May 28, 2026
…ger (#76) 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.
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
ci-safety.yml'sname:fromDependency Safety→CI Safetyto disambiguate it from the reusabledependency-safety.ymlworkflow it consumes (which also declaresname: Dependency Safety).Why
After #71 merged, a phantom startup-failure run appeared on the merge commit: run 26556546736 — 0 jobs, no logs,
event: pushagainst a workflow (dependency-safety.yml) whoseon:block contains onlyworkflow_call:.Diagnosis: GitHub registered
ci-safety.ymlfirst as workflow id281950779with nameDependency Safety. Whendependency-safety.ymlwas added at the same time, GitHub couldn't reuse the name and fell back to registering id281959865with the file path as the display name. That unresolvable name causes GitHub's check-suite scheduler to emit phantom startup-failure runs (0 jobs, no logs) on pushes that modifydependency-safety.yml. The same phantom failure also fired on thefix/gate-status-target-urlbranch push (run 26556360487) but wasn't tied to PR #71's check rollup so it didn't show up ingh pr checks.Sister
workflow_call-only workflows (tag-release.yml,release.yml) have unique names and produce no phantom runs, confirming that the collision — not "workflow_call-only-ness" — is what triggers the bug.Test plan
ci-scripts.yml(bats + inline-sync + workflow-call lint) is green on this PR.CI Safetyworkflow (formerly "Dependency Safety") runs on this PR's non-bot early-exit path and passes..github/workflows/dependency-safety.yml. (If GitHub's workflow registry needs a beat to re-resolve names, may take one merge cycle to take effect.)Dependency Safetyworkflow still runs end-to-end on a real Dependabot PR and thedependency-safety / gatestatus row remains clickable (validates the fix(safety): make dependency-safety/gate status clickable #71 fix is unaffected).