fix(renovate): move the three VictoriaMetrics images as one PR #445

Sammanfogat

supernaut sammanfogade 1 incheckning från fix/group-victoriametrics-lockstep in i main

2026-08-19 06:50:27 +00:00

supernaut kommenterad

2026-08-19 06:46:20 +00:00

Ägare

Needed before Monday 2026-08-24, when the scheduled Renovate run creates branches for the eight
updates now sitting in Awaiting Schedule. Three of them are the VictoriaMetrics trio.

The invariant nothing enforced

The three images are pinned in three separate places, across two roles and two hosts, and two of the
pins carry a comment requiring lockstep:

monitoring-agent/defaults  vmagent_image_tag:         "v1.147.0"  # keep in lockstep with the VM/vmalert tags
monitoring/defaults        victoriametrics_image_tag: "v1.147.0"
monitoring/defaults        vmalert_image_tag:         "v1.147.0"  # keep in lockstep with victoriametrics_image_tag

Nothing enforced it. Ungrouped, one upstream release produces three PRs, and merging them at
different times leaves the versions diverged across the remote_write boundary.

Reproduced, with a control

Run with platform=local and dry-run=full against renovate:43, which is what Monday's scheduled
run does. No token, no production access, no apply.

Branches Renovate decided on	victoria-metrics	vmagent	vmalert	total
Control (rule removed)	`…-victoria-metrics-1.x`	`…-vmagent-1.x`	`…-vmalert-1.x`	3
With the rule	grouped	grouped	grouped	1 (`renovate/victoriametrics`)

All three resolve to v1.150.0. loki and alertmanager kept their own branches in both runs,
so the group is scoped rather than a blanket one.

The control is the part that matters. A matchDepNames that matched nothing would produce a passing
config, no error, and three branches, which is indistinguishable from a rule that works. The shared
preset's own description warns about exactly this for matchDepTypes: "a depType that matches nothing
fails silently and looks exactly like a rule that works."

Choices

Repo-local, not in the shared preset. These images exist in no other bitborg repo (checked all
six), and the preset reserves per-repo files for "genuinely repo-specific rules". Same precedent as
the forgejo/postgres major gate already here.

No matchUpdateTypes. Renovate's default separateMajorMinor already splits a major into its own
branch, where the global major gate still holds it for dashboard approval. Adding the constraint
would be redundant and would suggest a protection that comes from elsewhere.

Same shape as the preset's toolchain group, which exists because Node is pinned twice and the two
pins "could silently drift to different Node versions". This is that, with three literals.

Note for whoever merges the grouped PR

It spans two hosts: vmagent runs on the services host, victoria-metrics and vmalert on the
monitoring VM. So it needs an apply to both. That is the point rather than a drawback. Bumping
vmalert also changes the image scripts/check-alert-rules.py validates against, which needs no
action because that script reads the tag from role defaults rather than a second literal.

Needed before Monday 2026-08-24, when the scheduled Renovate run creates branches for the eight updates now sitting in **Awaiting Schedule**. Three of them are the VictoriaMetrics trio. ## The invariant nothing enforced The three images are pinned in three separate places, across two roles and two hosts, and two of the pins carry a comment requiring lockstep: ``` monitoring-agent/defaults vmagent_image_tag: "v1.147.0" # keep in lockstep with the VM/vmalert tags monitoring/defaults victoriametrics_image_tag: "v1.147.0" monitoring/defaults vmalert_image_tag: "v1.147.0" # keep in lockstep with victoriametrics_image_tag ``` Nothing enforced it. Ungrouped, one upstream release produces three PRs, and merging them at different times leaves the versions diverged across the `remote_write` boundary. ## Reproduced, with a control Run with `platform=local` and `dry-run=full` against `renovate:43`, which is what Monday's scheduled run does. No token, no production access, no apply. | Branches Renovate decided on | victoria-metrics | vmagent | vmalert | total | | --- | --- | --- | --- | --- | | **Control** (rule removed) | `…-victoria-metrics-1.x` | `…-vmagent-1.x` | `…-vmalert-1.x` | **3** | | **With the rule** | grouped | grouped | grouped | **1** (`renovate/victoriametrics`) | All three resolve to `v1.150.0`. `loki` and `alertmanager` kept their own branches in **both** runs, so the group is scoped rather than a blanket one. The control is the part that matters. A `matchDepNames` that matched nothing would produce a passing config, no error, and three branches, which is indistinguishable from a rule that works. The shared preset's own description warns about exactly this for `matchDepTypes`: "a depType that matches nothing fails silently and looks exactly like a rule that works." ## Choices **Repo-local, not in the shared preset.** These images exist in no other bitborg repo (checked all six), and the preset reserves per-repo files for "genuinely repo-specific rules". Same precedent as the forgejo/postgres major gate already here. **No `matchUpdateTypes`.** Renovate's default `separateMajorMinor` already splits a major into its own branch, where the global `major` gate still holds it for dashboard approval. Adding the constraint would be redundant and would suggest a protection that comes from elsewhere. **Same shape as the preset's `toolchain` group**, which exists because Node is pinned twice and the two pins "could silently drift to different Node versions". This is that, with three literals. ## Note for whoever merges the grouped PR It spans two hosts: `vmagent` runs on the services host, `victoria-metrics` and `vmalert` on the monitoring VM. So it needs an apply to **both**. That is the point rather than a drawback. Bumping `vmalert` also changes the image `scripts/check-alert-rules.py` validates against, which needs no action because that script reads the tag from role defaults rather than a second literal.

supernaut lade till 1 incheckning

2026-08-19 06:46:20 +00:00

fix(renovate): move the three VictoriaMetrics images as one PR

ci / ci (pull_request) Successful in 1m45s

Detaljer

a574aa04c0

victoria-metrics, vmagent and vmalert are pinned in three separate places,
and two of those pins carry a comment requiring lockstep:

  vmalert_image_tag  "keep in lockstep with victoriametrics_image_tag"
  vmagent_image_tag  "keep in lockstep with the VM/vmalert tags on the monitoring VM"

Nothing enforced it. Reproduced with platform=local and dry-run=full against
renovate 43, which is what Monday's scheduled run will do:

  without the rule   renovate/docker.io-victoriametrics-victoria-metrics-1.x
                     renovate/docker.io-victoriametrics-vmagent-1.x
                     renovate/docker.io-victoriametrics-vmalert-1.x
  with the rule      renovate/victoriametrics

All three resolve to v1.150.0. loki and alertmanager kept their own branches in
both runs, so the group is scoped rather than a blanket one. The control run
matters more than the result: a matchDepNames that matched nothing would look
exactly like a rule that works, which the shared preset's own description warns
about for matchDepTypes.

Same failure the preset's `toolchain` group prevents for the Node pins, with
three literals instead of two. Kept repo-local rather than added to the shared
preset because these images exist in no other bitborg repo, and the preset
reserves per-repo files for genuinely repo-specific rules.

No matchUpdateTypes: Renovate's default separateMajorMinor already splits a
major into its own branch, where the global major gate still holds it for
dashboard approval.

The grouped PR spans two hosts, since vmagent runs on the services host while
victoria-metrics and vmalert run on the monitoring VM. That needs an apply to
both, which is the point rather than a drawback.

supernaut refererade till denna ändringsförfrågan

2026-08-19 06:47:28 +00:00

renovate: forgejo 16.0.2 and postgres 17.11 stuck in Pending Status Checks with no branch #430

supernaut sammanfogade incheckning 80284ffbc9 till main

2026-08-19 06:50:27 +00:00

supernaut tog bort grenen fix/group-victoriametrics-lockstep

2026-08-19 06:50:27 +00:00

supernaut refererade denna ändringsförfrågan från en incheckning

2026-08-19 06:50:28 +00:00

fix(renovate): move the three VictoriaMetrics images as one PR (#445)

supernaut refererade denna ändringsförfrågan från en incheckning

2026-10-02 17:56:58 +00:00