fix(renovate): let Renovate see Bun releases (bun-v tag prefix)

[toini]

Problem

Renovate has never proposed a Bun bump in this repo. Bun has been pinned at 1.3.10 (Feb 2026) while 1.4.0 shipped 2026-08-20. The only bun/Node PRs here (#5, #10) were human-authored features, never Renovate bumps.

Root cause

The custom regex manager extracts BUN_VERSION with datasource=github-releases and versioningTemplate: semver. But Bun tags its GitHub releases with a bun-v prefix:

$ gh api repos/oven-sh/bun/releases --jq '.[0:3][] | .tag_name'
bun-v1.4.0
bun-v1.3.14
bun-v1.3.13

github-releases returns the tag name as the version. Under semver, bun-v1.4.0 is not a version, so every candidate was filtered out and the candidate list came back empty. Renovate then had nothing to compare and proposed nothing — with no error on the Dependency Dashboard, which is why this went unnoticed.

Reproduced locally with Renovate 44.42.2 against this repo at main (renovate --platform=local --dry-run=lookup):

INFO: Found no results from datasource that look like a version (dependency=oven-sh/bun)
      "result": {
        "sourceUrl": "https://github.com/oven-sh/bun",
        "releases": [],
        "registryUrl": "https://github.com"
      }

The bun dep resolved with no currentVersion / fixedVersion at all:

{ "depName": "oven-sh/bun", "currentValue": "1.3.10", "updates": [], "warnings": [] }

The control that proves it

Kiota goes through the exact same manager, datasource and versioning — and does get bumped (#13 → v1.34.1, #11 → v1.34.0). Its tags are bare v1.34.1, which Renovate's semver accepts (leading v tolerated). Same baseline run, Kiota resolves fully:

{ "depName": "microsoft/kiota", "currentValue": "v1.34.1",
  "currentVersion": "v1.34.1", "fixedVersion": "v1.34.1", "updates": [] }

The tag prefix is the only difference between the dep that works and the dep that never has.

The mechanism (this is the actual fix)

A bun-scoped packageRules entry carrying extractVersion:

{
  "matchDatasources": ["github-releases"],
  "matchDepNames": ["oven-sh/bun"],
  "extractVersion": "^bun-v(?<version>.+)$"
}

extractVersion matters twice: it makes the candidate list parse and it controls what gets written back. Renovate writes the extracted 1.4.0 (not bun-v1.4.0), so bash -s "bun-v${BUN_VERSION}" keeps composing correctly.

Because this is config-level, it covers 24/ and 26/ at once — no per-directory change needed.

Options considered

Option	Verdict
extractVersion on a bun-scoped packageRule	Chosen. Keeps the datasource aligned with what the installer actually fetches (a GitHub release tag), and leaves Kiota untouched.
extractVersion on the customManager	Rejected — invalid config. Not merely a Kiota hazard: Renovate refuses the field there entirely, and the whole run aborts in the init phase (evidence below).
datasource=npm depName=bun	Rejected. Clean semver, but it decouples the version source from the install mechanism — bun.sh/install resolves a GitHub release tag, so npm could offer a version whose GH tag isn't published yet and the image build would fail. npm also carries daily canary prereleases (1.4.0-canary.20260824.1) and would lean on ignoreUnstable defaults to filter them.
versioning: loose on bun	Rejected. Would write the full tag back into BUN_VERSION, producing bun-vbun-v1.4.0 in the install line.

Why the customManager route is rejected, verbatim

$ renovate-config-validator --no-global .github/renovate.json
ERROR: Found errors in configuration
       "errors": [{ "topic": "Configuration Error",
         "message": "Custom Manager contains disallowed fields: extractVersion" }]

In a full run that surfaces as WARN: Repository has invalid config and Skipping the rest to the Renovate run due to error in init phase — i.e. it would have broken all updates in this repo, Kiota and Docker included.

Catch-up (separable from the mechanism)

BUN_VERSION 1.3.10 → 1.4.0 in both 24/Dockerfile and 26/Dockerfile — exactly the bump Renovate now proposes on its own. Revert these two lines and the mechanism still stands on its own.

Confirmed bun-linux-x64.zip exists on the bun-v1.4.0 release, so the install line resolves.

Verification

Renovate 44.42.2, --platform=local --dry-run=lookup, against real GitHub datasources.

1. Config validation (repo-config mode, strict):

$ renovate-config-validator --no-global --strict .github/renovate.json
 INFO: Validating .github/renovate.json as repo config
 INFO: Config validated successfully against 1 file(s)
EXIT=0

2. Mechanism works — fix applied, BUN_VERSION left at 1.3.10. Both Dockerfiles produced:

"updates": [{ "newVersion": "1.4.0", "newValue": "1.4.0", "updateType": "minor",
              "isBreaking": false, "branchName": "renovate/oven-sh-bun-1.x" }]

Note newValue: "1.4.0" — prefix stripped, as required.

3. Kiota unharmed — its resolved dep block in the fixed run is byte-identical to baseline (currentVersion: v1.34.1, fixedVersion: v1.34.1, updates: [] since it is already latest).

4. Settles when current — with the catch-up applied, bun reports currentVersion: 1.4.0, fixedVersion: 1.4.0, updates: [], and zero "no results" warnings.

Not verified

This repo has no CI — no .github/workflows, no .circleci/config.yml; the README states the image is built in Docker Hub. So nothing on this PR builds the Dockerfiles, and the 1.4.0 install is unproven until Docker Hub rebuilds after merge. That is equally true of any Renovate-authored bump here, so it is not a regression introduced by this PR — but it does mean no green check on this PR implies the image builds.

[tibber-agents]

🤖 tibber-agents[bot] is reviewing this PR. View progress live.

[tibber-agents]

Automated PR review by tibber-agents[bot] · anthropic-claude-opus-4.8. Advisory only — humans decide whether to merge.

Summary

Correct, well-scoped fix. The root cause (Bun's bun-v tag prefix breaking github-releases + semver candidate parsing) and the mechanism (a bun-scoped extractVersion on packageRules, not on customManager) are both diagnosed accurately, and the config change leaves Kiota untouched. I independently confirmed bun-v1.4.0 exists with a bun-linux-x64.zip asset, so the reconstructed bun-v${BUN_VERSION} install line resolves. No actionable issues.

Issues

No actionable issues found.

Notes (non-blocking):

• The extractVersion scoping is sound: it matches matchDatasources: ["github-releases"] and matchDepNames: ["oven-sh/bun"], so Kiota (microsoft/kiota, bare v1.34.1) is not rewritten. Because it lives on packageRules it applies across both 24/ and 26/ without per-directory changes.
• As the description candidly notes, this repo has no CI, so nothing on this PR builds the Dockerfiles — the 1.4.0 image build is unproven until Docker Hub rebuilds after merge. That is true of any bump here, not a regression from this PR.

Conventions consulted

• .agent/rubric/org-wide-instructions.md
• README.md
• catalog-info.yaml

[toini]

@tibber-agents please re-review

Scope reduced since your review: I reverted the catch-up bump, so this PR is now the mechanism fix only — the 6-line packageRules entry in .github/renovate.json. Both Dockerfiles are back at BUN_VERSION=1.3.10.

Reason: with the pin already at 1.4.0 the dep resolves to updates: [], which is indistinguishable from the extractVersion fix not working. Leaving the pin stale means the next Renovate run has to actually propose 1.4.0 — that PR appearing is the observable proof, and it arrives as its own reviewable, revertable change rather than buried in a config commit. It also matters because this repo has no CI at all (.github/ holds only CODEOWNERS and renovate.json), so nothing here would have built the 1.4.0 image anyway.

Worth confirming independently if you can: Renovate has updated microsoft/kiota (#13, #11, #7) and cimg/node (#15, #12, #8) in this repo but has never opened a bun PR, despite the annotation being present — the tag prefix (bun-v1.4.0 vs Kiota's bare v1.34.1) is the only difference between the dep that works and the one that never has.

[tibber-agents]

Automated PR review by tibber-agents[bot] · anthropic-claude-opus-4.8. Advisory only — humans decide whether to merge.

Summary

Re-review after scope reduction (8eeca3f → 9fee152): the catch-up BUN_VERSION bump is reverted, so this PR is now purely the mechanism fix — a single 6-line bun-scoped packageRules entry in .github/renovate.json with extractVersion: "^bun-v(?<version>.+)$". I independently confirmed the root cause the operator asked me to check: across this repo's Renovate history, app/renovate has opened PRs for microsoft/kiota (#13/#11/#7) and cimg/node (#15/#12/#8/#2) — both through the same custom manager/datasource — but has never opened a bun PR; bun landed only via human-authored #5. The bun-v tag prefix vs Kiota's bare v1.34.1 is the only difference, exactly as diagnosed, and the regex is correctly scoped by matchDepNames: ["oven-sh/bun"] so Kiota's writeback is untouched. I'm approving: this is now a minimal, single-concern config change, correct by inspection, and the decision to leave the pin stale so the next Renovate run produces observable proof is sound (with the pin already at 1.4.0 the dep resolves updates: [], indistinguishable from the fix not working).

Issues

No actionable issues found.

The reduced scope also removes the only caveat from my first review — the previously-bundled 1.4.0 image build that no CI here would exercise (this repo has no .github/workflows or .circleci/config.yml; the image builds in Docker Hub post-merge). That risk now moves to a future Renovate-authored bump PR, which is its own reviewable, revertable change — a strict improvement.

Conventions consulted

• .agent/rubric/org-wide-instructions.md
• README.md
• catalog-info.yaml