fix(safety): rename workflow name to force registry refresh#74
Merged
Conversation
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.
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
dependency-safety.yml'sname:fromDependency Safety→Dependency Safety (reusable).name:value itself changes.Why
The
ci-safety.ymldogfood has been silently broken since 2026-05-28 — every PR produces a 0-job phantom failure because workflow ID281959865(dependency-safety.yml) has a stale registered display name (".github/workflows/dependency-safety.yml", the file-path fallback). Three prior attempts to refresh it failed:ci-safety.ymlto break the original name collision) — refreshedci-safety.yml's record but not this one.disable/enablecycle — state wentactive → disabled_manually → active,updated_atadvanced, butnamefield stayed at the path fallback.updated_atadvanced again, butnamestill stuck.This implies GitHub re-resolves the registered name only when the actual YAML
name:value differs from what's recorded — file-touch alone isn't enough, and API state cycles don't trigger resolution at all.Test plan
gh api repos/j7an/shared-workflows/actions/workflows/281959865 --jq '{id, name, updated_at}'nameis"Dependency Safety (reusable)"→ resolver runs onname:value changes. Decide whether to rename back via a follow-up PR.nameis still".github/workflows/dependency-safety.yml"→ GitHub-side bug confirmed. Open support ticket with workflow ID and run IDs26556546736,26557110156,26557123379,26557302648.safety / scanjob again — confirming the dogfood pipeline is restored.Rollback
The display name change is cosmetic. If we want to rename back to
Dependency Safetyafter confirming the refresh works, a follow-up one-line PR does it. Consumer repos see the row label change, but theuses:path is unaffected — no breaking change.