fix(safety): make dependency-safety/gate status clickable#71
Merged
Conversation
The gate row in PR check rollups was rendered with empty target_url because the legacy Statuses API calls didn't set one. Users had to manually locate the Dependency Safety workflow run under the Actions tab to inspect a failed or stuck-pending gate. Add target_url pointing at the current workflow run to all three gh api .../statuses/... calls (non-bot success, Dependabot pending, and final state). In workflow_call context, github.server_url / .repository / .run_id resolve to the caller's run — which is where the safety/scan logs live. No script changes; no inline-sync impact.
4 tasks
j7an
added a commit
that referenced
this pull request
May 28, 2026
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).
This was referenced May 28, 2026
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
j7an
added a commit
that referenced
this pull request
May 28, 2026
#77) Restore the clickable gate-status feature originally attempted in #71, this time using shell environment variables instead of GitHub Actions template-expression syntax. #71's form (now removed from history): -f target_url="${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" caused GitHub Actions' scheduler to abort caller invocations of this reusable workflow before any job launched — a 0-job startup_failure with no logs. The dogfood (ci-safety.yml → dependency-safety.yml) was silently broken for ~24 hours until the cause was localized to those three expressions. This commit uses the shell-env-var form instead: -f target_url="${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID}" Identical runtime values — GitHub Actions exports these as standard env vars to the runner — but GitHub's template-expression analyzer sees no ${{ }} substitution in the target_url area. Hypothesis: the scheduler's expression analyzer specifically tripped on the previous form; bypassing template substitution should sidestep it. If this PR's ci-safety dogfood produces a real `safety / scan` job AND the resulting `dependency-safety / gate` row in the PR check rollup becomes clickable, the workaround is confirmed. If the dogfood breaks again (0-job phantom), revert this PR; the bug is about target_url presence regardless of substitution form, and we live with an unclickable gate.
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
target_urlto all threegh api .../statuses/...calls independency-safety.ymlso thedependency-safety / gatePR check row becomes clickable.${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}) — inworkflow_callcontext this resolves to the caller's run, where thesafety / scanlogs live.Why
The gate row was rendered as a `StatusContext` with empty `targetUrl`, so users couldn't click through to see why a gate was failing or stuck pending. The legacy Statuses API documents `target_url` as optional but unused-by-default; we just hadn't been setting it.
Test plan