feat(renovate): open bump PRs for new Upstream Versions #27

Merged
piscis merged 2 commits from piscis/forgejo-issue-8-implement into main 2026-09-30 15:35:17 +00:00
Owner

Closes #8. Supersedes onboarding PR #13.

Summary

renovate.json turns on the self-hosted bot and gives it exactly one job: bump the Pin.

 # pin.env (what a bump PR changes)
-UPSTREAM_VERSION=v3.1.0
-UPSTREAM_COMMIT=369de3dbcf27e24bb0d45b8cb7219f42aafce88c
+UPSTREAM_VERSION=v3.2.0
+UPSTREAM_COMMIT=e30bb7e2e45c0e447506b5df1fe83ebce4b43944   # peeled commit, not the tag object 931a525d
 REBUILD=1          # untouched
 REBUILD_OF=v3.1.0  # untouched → no longer matches, so the Rebuild is 1 (ADR 0003)
renovate.json
  enabled: true                       # the bot skips repos without it
  enabledManagers: [custom.regex]     # only the Pin; no Dockerfile/Actions PRs
  dependencyDashboard: false          # no bot issue in the triage tracker
  hostRules: git.b4mad.industries → forgejo   # lets Renovate pull Upstream release notes
  customManagers[regex] on pin.env
    UPSTREAM_VERSION=(currentValue)  UPSTREAM_COMMIT=(currentDigest)
    datasource git-tags @ https://git.b4mad.industries/agentic-forges/forgejo-mcp (ADR 0002)
  packageRules (forgejo-mcp)
    allowedVersions /^v\d+\.\d+\.\d+$/          # stable semver only
    separateMajorMinor: false, branchTopic forgejo-mcp  # always one PR on renovate/forgejo-mcp
    prBodyNotes: link to Upstream release tag
    digest updates disabled                     # a moved tag is for the Dockerfile check to catch, not to auto-propose
  • Commit, not the tag object: all Upstream tags are annotated. Renovate's git-tags datasource (checked in 43.288.0 source, git-refs/base.js) replaces each tag's hash with its ^{} peeled hash, the same check make verify-pin from #26 runs.
  • No postUpgradeTasks, and REBUILD/REBUILD_OF sit outside the match, so Renovate can't touch them.
  • #13: superseded, not merged. It only adds a bare $schema file, and it would clash with this file (both add renovate.json). Once this merges the repo counts as onboarded. Renovate prunes renovate/configure only if it considers the branch unmodified; my dry run skipped the deletion ("Orphan Branch is modified", probably because my run didn't have the bot's git author). If #13 is still open after the bot's first run, close it by hand.
  • Base-image (Dockerfile) and Actions bumps are deliberately out of scope. They would need a hand-raised Rebuild (ADR 0003), so they belong in a follow-up ticket.

Evidence

Config validation (Renovate 43.288.0, same major as the bot's ghcr.io/renovatebot/renovate:43; also passes on 44.125.1):

$ renovate-config-validator --strict
 INFO: Validating renovate.json
 INFO: Config validated successfully against 1 file(s)

Regex against pin.env (node script: the manager's pattern, run with JS RegExp):

fileMatch pin.env: true
matches: 1
{ currentValue: 'v3.2.0', currentDigest: 'e30bb7e2e45c0e447506b5df1fe83ebce4b43944' }
allowedVersions v3.3.0 true | v3.0.0-alpha.1 false | v4.0.0-rc.1 false | 3.3.0 false

Lookup scenarios (renovate --platform=local --dry-run=full, a copy of the repo with pin.env edited, live lookups against Upstream):

Pin Result
v3.2.0 / e30bb7e2 (current) no updates, Returning 0 branch(es)
v3.1.0 / 369de3db (one behind) → v3.2.0 / e30bb7e2e45c0e447506b5df1fe83ebce4b43944, minor, renovate/forgejo-mcp, 1 branch
v2.9.1 (a major behind) → v3.2.0 / e30bb7e2…, one branch renovate/forgejo-mcp (no separate 2.x PR)
v3.0.0-alpha.1 → v3.2.0 (stable); v3.0.0-alpha.1 itself is never proposed
v3.2.0 / 0000… (tag "moved") digest update found but disabled: Returning 0 branch(es)

Forgejo dry run against this repo (the -p node@24 wrapper only supplies the Node version Renovate needs; --onboarding=false and RENOVATE_CONFIG_FILE pass this branch's renovate.json because main has none yet):

$ RENOVATE_CONFIG_FILE=renovate.json RENOVATE_TOKEN=… npx -p node@24 node …/renovate.js \
    --platform=forgejo --endpoint=https://code.vicoli.de/api/v1 --dry-run=full \
    --onboarding=false --require-config=optional vicoli-oss/docker-forgejo-mcp
Renovate started {"renovateVersion": "43.288.0"}
Dependency extraction complete {"stats": {"managers": {"regex": {"fileCount": 1, "depCount": 1}}}}
packageFiles with updates {"depName": "forgejo-mcp", "currentValue": "v3.2.0", "currentDigest": "e30bb7e2…", "datasource": "git-tags", "updates": []}
Returning 0 branch(es)
Repository result: done, status: activated, enabled: true, onboarded: true

Release notes in the PR body: I called Renovate's getChangeLogJSON directly with the hostRule set:

platform without hostRule: null
platform with hostRule: forgejo
v3.2.0 releaseNotes.url: https://git.b4mad.industries/agentic-forges/forgejo-mcp/releases/tag/v3.2.0
       body: "#### Changelog\n\n- [`e30bb7e`](…) chore(release): 3.2.0 …"

If that fetch ever fails, prBodyNotes still links …/releases/tag/<newVersion>.

Needs a live bot run

These depend on the deployed bot and a real Upstream release, so this PR doesn't claim them. Steps to check each one after merge:

  1. One version behind → exactly one PR, Rebuild 1, CI green. On a scratch branch off main, set the Pin to UPSTREAM_VERSION=v3.1.0, UPSTREAM_COMMIT=369de3dbcf27e24bb0d45b8cb7219f42aafce88c, REBUILD_OF=v3.1.0, and merge it. (Or wait for Upstream's next release, which avoids touching main.) Within ~5 min (the bot runs @every 300s), check: exactly one open PR from renovatebot on renovate/forgejo-mcp; its diff changes only UPSTREAM_VERSION→v3.2.0 and UPSTREAM_COMMIT→e30bb7e2e45c0e447506b5df1fe83ebce4b43944; the body links the Upstream release; make print-tag on that branch prints 3.2.0-r1; the PR CI (#6) runs and the Dockerfile's commit check and smoke test pass.
  2. Updates instead of duplicating. With that PR open, wait for the next run or tick the rebase checkbox. Check it's still one PR, same number, force-pushed. Across a newer Upstream release, the same renovate/forgejo-mcp PR is retargeted, because branchTopic has no major in it.
  3. Pin current → nothing. After merging/reverting so the Pin is v3.2.0/e30bb7e2…, check the next bot run opens no PR and the bot log shows forgejo-mcp … updates: [].
  4. Pre-releases ignored. When Upstream next pushes a -alpha/-rc tag, check no PR appears. (Covered offline by allowedVersions above.)
  5. #13 closed. After the first run on main, check #13 is closed/autoclosed; if not, close it by hand.

Merge Danger

Door: two-way

Reverting renovate.json (or setting "enabled": false) stops the bot. Any bump PR it has opened can simply be closed.

Blast Radius: small

It only affects this repo's bot behaviour. The bot's PRs change only pin.env, and they merge (and publish via #7) only after human review. Merging turns off the onboarding flow for good: #13 is superseded, and Renovate won't reopen an onboarding PR.

Closes #8. Supersedes onboarding PR #13. ## Summary `renovate.json` turns on the self-hosted bot and gives it exactly one job: bump the Pin. ```diff # pin.env (what a bump PR changes) -UPSTREAM_VERSION=v3.1.0 -UPSTREAM_COMMIT=369de3dbcf27e24bb0d45b8cb7219f42aafce88c +UPSTREAM_VERSION=v3.2.0 +UPSTREAM_COMMIT=e30bb7e2e45c0e447506b5df1fe83ebce4b43944 # peeled commit, not the tag object 931a525d REBUILD=1 # untouched REBUILD_OF=v3.1.0 # untouched → no longer matches, so the Rebuild is 1 (ADR 0003) ``` ```text renovate.json enabled: true # the bot skips repos without it enabledManagers: [custom.regex] # only the Pin; no Dockerfile/Actions PRs dependencyDashboard: false # no bot issue in the triage tracker hostRules: git.b4mad.industries → forgejo # lets Renovate pull Upstream release notes customManagers[regex] on pin.env UPSTREAM_VERSION=(currentValue) UPSTREAM_COMMIT=(currentDigest) datasource git-tags @ https://git.b4mad.industries/agentic-forges/forgejo-mcp (ADR 0002) packageRules (forgejo-mcp) allowedVersions /^v\d+\.\d+\.\d+$/ # stable semver only separateMajorMinor: false, branchTopic forgejo-mcp # always one PR on renovate/forgejo-mcp prBodyNotes: link to Upstream release tag digest updates disabled # a moved tag is for the Dockerfile check to catch, not to auto-propose ``` - **Commit, not the tag object:** all Upstream tags are annotated. Renovate's git-tags datasource (checked in 43.288.0 source, `git-refs/base.js`) replaces each tag's hash with its `^{}` peeled hash, the same check `make verify-pin` from #26 runs. - **No `postUpgradeTasks`**, and `REBUILD`/`REBUILD_OF` sit outside the match, so Renovate can't touch them. - **#13: superseded, not merged.** It only adds a bare `$schema` file, and it would clash with this file (both add `renovate.json`). Once this merges the repo counts as onboarded. Renovate prunes `renovate/configure` only if it considers the branch unmodified; my dry run skipped the deletion ("Orphan Branch is modified", probably because my run didn't have the bot's git author). **If #13 is still open after the bot's first run, close it by hand.** - Base-image (Dockerfile) and Actions bumps are deliberately out of scope. They would need a hand-raised Rebuild (ADR 0003), so they belong in a follow-up ticket. ## Evidence **Config validation** (Renovate 43.288.0, same major as the bot's `ghcr.io/renovatebot/renovate:43`; also passes on 44.125.1): ``` $ renovate-config-validator --strict INFO: Validating renovate.json INFO: Config validated successfully against 1 file(s) ``` **Regex against `pin.env`** (node script: the manager's pattern, run with JS `RegExp`): ``` fileMatch pin.env: true matches: 1 { currentValue: 'v3.2.0', currentDigest: 'e30bb7e2e45c0e447506b5df1fe83ebce4b43944' } allowedVersions v3.3.0 true | v3.0.0-alpha.1 false | v4.0.0-rc.1 false | 3.3.0 false ``` **Lookup scenarios** (`renovate --platform=local --dry-run=full`, a copy of the repo with `pin.env` edited, live lookups against Upstream): | Pin | Result | |---|---| | `v3.2.0` / `e30bb7e2` (current) | no updates, `Returning 0 branch(es)` | | `v3.1.0` / `369de3db` (one behind) | → `v3.2.0` / `e30bb7e2e45c0e447506b5df1fe83ebce4b43944`, minor, `renovate/forgejo-mcp`, 1 branch | | `v2.9.1` (a major behind) | → `v3.2.0` / `e30bb7e2…`, one branch `renovate/forgejo-mcp` (no separate 2.x PR) | | `v3.0.0-alpha.1` | → `v3.2.0` (stable); `v3.0.0-alpha.1` itself is never proposed | | `v3.2.0` / `0000…` (tag "moved") | digest update found but disabled: `Returning 0 branch(es)` | **Forgejo dry run against this repo** (the `-p node@24` wrapper only supplies the Node version Renovate needs; `--onboarding=false` and `RENOVATE_CONFIG_FILE` pass this branch's `renovate.json` because `main` has none yet): ``` $ RENOVATE_CONFIG_FILE=renovate.json RENOVATE_TOKEN=… npx -p node@24 node …/renovate.js \ --platform=forgejo --endpoint=https://code.vicoli.de/api/v1 --dry-run=full \ --onboarding=false --require-config=optional vicoli-oss/docker-forgejo-mcp Renovate started {"renovateVersion": "43.288.0"} Dependency extraction complete {"stats": {"managers": {"regex": {"fileCount": 1, "depCount": 1}}}} packageFiles with updates {"depName": "forgejo-mcp", "currentValue": "v3.2.0", "currentDigest": "e30bb7e2…", "datasource": "git-tags", "updates": []} Returning 0 branch(es) Repository result: done, status: activated, enabled: true, onboarded: true ``` **Release notes in the PR body**: I called Renovate's `getChangeLogJSON` directly with the hostRule set: ``` platform without hostRule: null platform with hostRule: forgejo v3.2.0 releaseNotes.url: https://git.b4mad.industries/agentic-forges/forgejo-mcp/releases/tag/v3.2.0 body: "#### Changelog\n\n- [`e30bb7e`](…) chore(release): 3.2.0 …" ``` If that fetch ever fails, `prBodyNotes` still links `…/releases/tag/<newVersion>`. ### Needs a live bot run These depend on the deployed bot and a real Upstream release, so this PR doesn't claim them. Steps to check each one after merge: 1. **One version behind → exactly one PR, Rebuild 1, CI green.** On a scratch branch off `main`, set the Pin to `UPSTREAM_VERSION=v3.1.0`, `UPSTREAM_COMMIT=369de3dbcf27e24bb0d45b8cb7219f42aafce88c`, `REBUILD_OF=v3.1.0`, and merge it. (Or wait for Upstream's next release, which avoids touching `main`.) Within ~5 min (the bot runs `@every 300s`), check: exactly one open PR from `renovatebot` on `renovate/forgejo-mcp`; its diff changes only `UPSTREAM_VERSION`→`v3.2.0` and `UPSTREAM_COMMIT`→`e30bb7e2e45c0e447506b5df1fe83ebce4b43944`; the body links the Upstream release; `make print-tag` on that branch prints `3.2.0-r1`; the PR CI (#6) runs and the Dockerfile's commit check and smoke test pass. 2. **Updates instead of duplicating.** With that PR open, wait for the next run or tick the rebase checkbox. Check it's still one PR, same number, force-pushed. Across a newer Upstream release, the same `renovate/forgejo-mcp` PR is retargeted, because `branchTopic` has no major in it. 3. **Pin current → nothing.** After merging/reverting so the Pin is `v3.2.0`/`e30bb7e2…`, check the next bot run opens no PR and the bot log shows `forgejo-mcp … updates: []`. 4. **Pre-releases ignored.** When Upstream next pushes a `-alpha`/`-rc` tag, check no PR appears. (Covered offline by `allowedVersions` above.) 5. **#13 closed.** After the first run on `main`, check #13 is closed/autoclosed; if not, close it by hand. ## Merge Danger **Door:** two-way Reverting `renovate.json` (or setting `"enabled": false`) stops the bot. Any bump PR it has opened can simply be closed. **Blast Radius:** small It only affects this repo's bot behaviour. The bot's PRs change only `pin.env`, and they merge (and publish via #7) only after human review. Merging turns off the onboarding flow for good: #13 is superseded, and Renovate won't reopen an onboarding PR.
A custom regex manager bumps UPSTREAM_VERSION and UPSTREAM_COMMIT in pin.env
together from the canonical Upstream's git tags. The git-tags datasource
peels annotated tags, so the commit is the one the tag points to. REBUILD and
REBUILD_OF stay untouched (ADR 0003). Supersedes the onboarding PR #13.
chore(renovate): no Dependency Dashboard issue in the triage tracker
All checks were successful
ci / build (pull_request) Successful in 10s
9f95f6210d
piscis merged commit 095833e922 into main 2026-09-30 15:35:17 +00:00
Sign in to join this conversation.
No description provided.