fix(renovate): cover every kernel pin — both 6.18 defconfigs, and 7.2-rc separately

[mcfbytes]

Based on feat/ci-rt-kernel (#39), since configs/mister_kernel_defconfig and configs/mister_rt.fragment only exist there.

What went wrong

The 6.18 manager matched only configs/mister_de10nano_defconfig, so the 6.18.38 → 6.18.39 bump landed in one of the two files carrying the pin and left configs/mister_kernel_defconfig behind. check-kernel-defconfig-sync.sh caught it loudly and correctly — but Renovate shouldn't have created the drift.

One clarification: Renovate didn't literally miss it. mister_kernel_defconfig doesn't exist on master, and Renovate only reads the default branch, so it couldn't have seen the file. The gap is forward-looking — once #39 merges, every future kernel bump drifts the same way. That's what this fixes.

The drift itself is already resolved on this branch by your a7472ef; this PR contains no defconfig change.

6.18 — one manager, both files, one PR

Both defconfigs are now listed in a single manager. They share a depName, so Renovate emits one PR touching both.

Verified against a real renovate --platform=local --dry-run=full with both files held back at 6.18.38:

extracted kernel-longterm-6.18 currentValues: ['6.18.39', '6.18.38', '6.18.38']
branches for that dep: ['renovate/kernel-longterm-6.18-6.x']  -> count = 1
defconfig packageFiles seen: ['configs/mister_de10nano_defconfig',
                              'configs/mister_kernel_defconfig']

Two upgrades, one branch. That's the grouping property, tested rather than assumed — my first attempt only held one file back, which couldn't have proven it.

7.2-rc — a deliberately separate manager

configs/mister_rt.fragment carries the identical Kconfig symbol but pins mainline -rc. It gets its own manager, its own kernelMainline datasource (moniker=mainline), and its own depName.

Sharing one manager would hand the longterm datasource a -rc currentValue and the mainline datasource a 6.18.x one. Both file patterns name their files explicitly rather than globbing configs/, which would silently re-couple them.

Verified in the same run: with the fragment held back at 7.2-rc1, it produced a separate renovate/kernel-mainline-rt-7.x branch proposing 7.2-rc3, and never proposed a 6.18 value for it.

The new datasource wraps its $map in [ ] for the reason already documented on kernelLongterm618: releases.json carries exactly one mainline entry, JSONata collapses a single-element sequence to a bare object, and Renovate rejects that as no-result silently.

The RT hash genuinely cannot be automated

Labeled needs-manual-hash, and that isn't decorative. kernel.org signs no -rc manifest, and Buildroot fetches -rc as a cgit .tar.gz snapshot from git.kernel.org — so renovate-hash-sync.yml's kernel step deliberately leaves that line alone (its own comment says exactly this, and matches the release tarball by filename rather than "first sha256 line" precisely so it can't clobber the -rc entry).

An RT bump PR is therefore expected to be red at the kernel download (No hash found for linux-<ver>.tar.gz, because BR2_DOWNLOAD_FORCE_CHECK_HASHES empties Buildroot's BR_NO_CHECK_HASH_FOR exemption) until a human TOFU-pins the hash per linux.hash's own -rc block. Same intended failure shape as BUILDROOT_SHA256.

Also carries needs-manual-version-check, for the same reason bcm20702-firmware does: loose versioning's ordering of an -rcN suffix isn't something to trust blindly.

Also

• Added configs/mister_kernel_defconfig to the hash-sync paths: filter. mister_rt.fragment is deliberately left out — nothing there can be auto-synced, so triggering the workflow for it would only burn a runner.
• renovate.json validates clean: 19 customManagers, 2 custom datasources, no no-result lookups in the dry run.

Not fixed here

actionlint still flags head.ref as an untrusted expression in the commit-and-push step on this branch. That's fixed in #45 against master; re-fixing it here would muddy this diff.

Related

I also pushed a fix to #43 renumbering its ADR 0021 → 0022 — this branch already claims 0021-rt-kernel-first-class-ci.md, and check-kernel-defconfig-sync.sh cites "ADR 0021" meaning that one. Whichever merged second would have silently redefined a referenced ADR number.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UFdgJXQKvrucXeKDami499

[Copilot]

Pull request overview

Updates Renovate configuration and documentation so kernel version pins are consistently managed across both 6.18 defconfigs, while keeping the RT/beta mainline -rc pin isolated with its own datasource/labels; also adjusts the hash-sync workflow trigger list to include the copied defconfig.

Changes:

• Add a kernelMainline custom datasource and a dedicated regex manager/packageRule for the RT/beta kernel pin.
• Expand the existing 6.18 longterm kernel manager to cover both configs/mister_de10nano_defconfig and configs/mister_kernel_defconfig under one depName (one PR).
• Update renovate-hash-sync.yml paths: filter and refresh docs to match the new managers/datasources.

Reviewed changes

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

File	Description
renovate.json	Adds mainline kernel datasource + RT manager/rules; extends 6.18 kernel manager to both defconfigs
docs/renovate.md	Documents the split longterm vs RT managers and updates managed-items counts/table
.github/workflows/renovate-hash-sync.yml	Triggers hash sync workflow when configs/mister_kernel_defconfig changes

---

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

[mcfbytes]

Copilot's finding was valid and is fixed in 39ed968 — and chasing it turned up a latent bug worth fixing alongside it.

The finding

Correct: the description claimed the matchString "requires the -rc shape specifically", but (?:-rc\d+)? makes the suffix optional, so a stable 7.2 also matches. Code and comment disagreed.

The regex is the correct half. docs/rt-beta-kernel.md picks 7.2 precisely because PREEMPT_RT landed for ARM in 7.1, so this pin follows the 7.2 line through its -rc series and out the other side — 7.2 final is the intended destination, not an accident. So I corrected the description rather than tightening the regex, and reworded the hash/label rationale, which likewise assumed -rc forever.

What that surfaced

Taking "stable mainline is reachable" seriously exposes a real bug. The kernel step matched its target line as linux-[0-9][0-9.]*\.tar\.xz, which is sufficient only while the RT pin is an -rc (Buildroot fetches those as a cgit .tar.gz). The moment that pin reaches a stable release it becomes linux-7.2.tar.xz — which the old pattern also matched.

Reproduced, with the RT line first:

before:  linux-7.2.tar.xz  /  linux-6.18.39.tar.xz
after:   linux-6.18.40.tar.xz  /  linux-6.18.39.tar.xz

The RT entry was destroyed and the stale 6.18 line survived — two 6.18 entries, no RT entry, RT build failing closed at download. Masked today only by the .tar.gz extension, and this PR is what makes the stable case reachable through automation, so it's fixed here rather than left for later.

Fix: scope the match to this pin's own major series (derived from $kver, not hardcoded), plus a guard that fails loudly if more than one line matches instead of guessing which the pin owns. The rewrite now replaces by exact string match on the line already found, rather than re-deriving a regex inside awk — awk -v eats backslash escapes, which would have silently turned \. into "any character".

Verification

case	result
collision (RT at stable 7.2, listed first)	RT line intact, 6.18 line updated
two same-series release lines	ambiguity guard fires, exits 1
today's real linux.hash	unchanged behaviour — RT .tar.gz untouched, 6.18 updated
end-to-end run of the real step, real tree	correct no-op, PATCH_HASH_CHANGED=0

renovate.json validates clean; 20 files / 21 deps extracted; no datasource lookup failures; shellcheck clean.