feat(ci): add a manual workflow_dispatch trigger to the hash sync

[mcfbytes]

Adds a workflow_dispatch trigger with a required branch input to renovate-hash-sync.yml.

Why this is necessary, not convenient

There is currently no way at all to re-drive this workflow after fixing a bug in it. Three things block every route, and all three held simultaneously on run 29669946883:

route	why it fails
push the fix to the branch	the paths: filter doesn't list the workflow file, so nothing triggers
a maintainer merges the fix in	the actor == renovate[bot] gate skips the job
re-run the failed run	a re-run replays the workflow definition from the commit the original run was created against — so it re-executes the old code

That run went through three attempts across two separate fixes and executed the same broken kernel-URL code every time. Confirmed by pulling attempt 3's log — it ran the pre-#42 unanchored grep, with none of #42's new comments present:

kver=$(grep -oE 'BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="[^"]+"' "$defconfig" \
"ANCHOR THIS GREP" present: 0
curl: (3) URL rejected: Malformed input to a URL function

Only Renovate moving the branch head, or a manual trigger, gets new code to run.

The input is the branch to repair, not the branch to run from

This distinction is the whole trap, so it's called out in the input description, the workflow header, and docs/renovate.md:

GitHub runs the workflow definition from the ref you dispatch on, while this workflow checks out and pushes to inputs.branch.

So: dispatch from the default branch (which has the fixed workflow) and name the broken branch — e.g. renovate/kernel-longterm-6.18-6.x — in the input. Dispatching on the stale branch would just run its stale copy again, reproducing the original problem.

Safety

• Manual runs refuse to target the default branch. This workflow commits and pushes; an auto-generated hash commit must go through a PR. An empty input is rejected too.
• The job gate doesn't widen. workflow_dispatch is already restricted to collaborators with write access — the same bar the renovate[bot] gate enforces on the automatic path.
• Concurrency keys on the target branch for dispatch runs, so manual runs don't all share one empty-suffix group and cancel each other.

Fixes the adjacent pre-existing injection finding

I flagged this on #43 as out of scope, but this PR touches exactly those expressions, so it's fixed here. The push step interpolated github.event.pull_request.head.ref straight into the script body — a command-injection vector, since a branch name is attacker-chosen text on a PR from an untrusted contributor. Both use sites now route through a job-level TARGET_BRANCH env var, and the push uses -- so a branch named like an option isn't parsed as one. actionlint's potentially untrusted warning is gone (was 1, now 0).

Two stale header claims corrected

• The header said this workflow "has never been exercised against a real Renovate PR". It has now — chore(deps): update dependency kernel-longterm-6.18 to v6.18.39 #41, kernel 6.18.38 → 6.18.39, end to end.
• More importantly, it undersold the failure mode: the warn-and-skip paths can report SUCCESS while doing nothing, which is exactly how the stale linux.hash went unnoticed through three green runs. The header now says to read every warn-and-skip path that way.

The github-package loop and the lzma-sdk / sdcard-payload steps remain genuinely unproven, and still say so.

Verification

• actionlint clean (apart from its stale runner-label list not knowing ubuntu-26.04, which every workflow in this repo trips).
• shellcheck clean on all six run: blocks.
• Guard logic exercised directly: a renovate branch passes; the default branch and an empty input are both rejected.
• actionlint also caught a real self-inflicted bug during authoring — a literal expression-looking token inside a run: comment, which it parses as an empty expression. Fixed before commit.

Note I could not execute a real dispatch run, since the trigger only exists once this is on the default branch. First live use will be its own proof.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UFdgJXQKvrucXeKDami499

[Copilot]

Pull request overview

Adds a manual workflow_dispatch escape hatch to the Renovate hash-sync workflow so maintainers can re-drive the hash refresh after workflow fixes land on the default branch, and updates the accompanying Renovate documentation to explain the “dispatch from vs. target branch” distinction.

Changes:

• Add workflow_dispatch with required branch input to .github/workflows/renovate-hash-sync.yml, plus branch-keyed concurrency for dispatch runs.
• Refactor target-branch handling into a single TARGET_BRANCH env var and use git push ... -- "HEAD:$TARGET_BRANCH" to avoid branch-name injection/option parsing.
• Document the manual dispatch behavior and rationale in docs/renovate.md.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
docs/renovate.md	Documents the new manual workflow_dispatch escape hatch and how to use the branch input safely.
.github/workflows/renovate-hash-sync.yml	Adds manual dispatch trigger, dispatch-safe concurrency grouping, target-branch resolution, and safer push behavior.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mcfbytes]

Valid finding, fixed in 0246991 — and the hole is wider than reported.

Verified with git push --dry-run

Three spellings all reach master, two of which bypassed the guard:

input	pushes to master	old guard
master	yes	caught
refs/heads/master	yes	bypassed — the finding
heads/master	yes	bypassed — not in the review

So the suggested fix of normalising away a refs/heads/ prefix would still have left heads/master open. (remotes/... and tags/... don't reach master, but do create junk refs, so they're rejected too.)

Rejecting, not normalising — deliberately

TARGET_BRANCH is consumed by both actions/checkout and the final git push. The value validated has to be the exact value those steps use. Normalising in the guard step would mean re-exporting through $GITHUB_ENV and depending on that overriding the job-level env: for subsequent steps — a precedence subtlety I don't want to bet a push to the default branch on. Rejecting keeps one value end to end.

Also added git check-ref-format --branch as a syntactic gate, and dropped the event_name == 'workflow_dispatch' condition so the automatic path gets validated too. Costs nothing, and means a PR head branch is checked as well.

All 12 cases

'renovate/kernel-longterm-6.18-6.x'  ALLOW
'feature/x'                          ALLOW
'master'                             REJECT (default branch)
'refs/heads/master'                  REJECT (not a plain branch name)
'heads/master'                       REJECT (not a plain branch name)
'refs/heads/other'                   REJECT (not a plain branch name)
'remotes/origin/master'              REJECT (not a plain branch name)
'tags/v1'                            REJECT (not a plain branch name)
'-x'                                 REJECT (invalid branch name)
'a..b'                               REJECT (invalid branch name)
'x y'                                REJECT (invalid branch name)
''                                   REJECT (empty)

Each rejection reports which rule fired. shellcheck clean; actionlint clean apart from its stale runner-label list.