renovate: no Forgejo or Postgres security release can bypass the weekly schedule #446

Nytt ärende

Öppen

öppnade 2026-08-19 06:46:51 +00:00 av supernaut · 0 kommentarer

supernaut kommenterad

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

Ägare

Related to #430, but a different claim. #430 is about updates held forever. This is about updates
held up to six days, by design, including for the git server.

The gap

A Forgejo or Postgres image security release cannot bypass the weekly schedule.

The shared preset sets schedule: ["before 6am on monday"] globally, and exempts security work:

"vulnerabilityAlerts": {
  "minimumReleaseAge": "0 days",
  "schedule": ["at any time"]
}

That exemption only reaches updates Renovate itself classifies as vulnerability alerts. Both
sources of that classification are unavailable here:

Platform vulnerability alerts. Renovate reads these from the forge. Forgejo does not provide
them, so there are none to read.
osvVulnerabilityAlerts: true. OSV covers package ecosystems (npm, PyPI, Go, crates and so on).
It has no ecosystem for a container image tag.

Forgejo and Postgres are tracked by customManagers in this repo with datasource=docker, matching a
*_image_tag line in Ansible vars. Renovate has no vulnerability feed for that. So the update is an
ordinary scheduled bump, and vulnerabilityAlerts never applies to it.

Neither this repo's renovate.json nor the shared preset gives forgejo or postgres a faster schedule.
The only rule naming them is the major gate, which slows them down rather than speeding them up.

Currently observable

forgejo 16.0.2 is in the Dependency Dashboard's Awaiting Schedule section right now, waiting for
Monday. Whether 16.0.2 carries security fixes has not been established here and should be checked
against the upstream release notes.

Why this is worth separating from #430

#430's acceptance says the outcome that matters is "a Forgejo security update reaching a reviewable
PR". Watching 16.0.2 open on Monday proves the timestamp-required bug from #430 is fixed. It does not
prove security updates arrive promptly, because Monday is exactly when a Monday-scheduled update would
open either way.

Two different properties, and one observation cannot distinguish them:

Not held forever. Fixed, and already evidenced: the entry moved from "Pending Status Checks" to
"Awaiting Schedule", and the dashboard now carries the minimumReleaseAgeBehaviour=timestamp-optional
WARN.
Arrives promptly when it is security. Not addressed, and not addressable by anything in the
current config.

Closing #430 on Monday is correct. It should not be read as closing this.

Options, not yet chosen

A faster schedule for the two critical images. A repo-local packageRule matching
codeberg.org/forgejo/forgejo and docker.io/library/postgres with a daily rather than weekly
window. Simple, and it applies whether or not a given release is security work. Costs a review of
ordinary patch bumps up to six days sooner than today.
Watch the upstream security feed directly and alert, rather than relying on Renovate to
classify. Forgejo publishes release announcements; an alert on "deployed tag is behind latest" is
independent of Renovate entirely and would also cover the case where Renovate is broken.
Accept and document. State the six-day worst case as a deliberate trade-off in the runbook so
it stops looking like an oversight. Weakest option, but honest, and better than the current state
where the config reads as though vulnerabilityAlerts covers this.

Option 1 is the cheapest real improvement; option 2 is the one that does not depend on Renovate being
healthy. They are complementary rather than alternatives.

Definition of done

A decision recorded here on which option is taken, with the reasoning
If a schedule change: shown to work with platform=local + dry-run=full AND a control run
without the rule, since a matchDepNames matching nothing looks identical to a rule that works
The runbook states the worst-case delay for a git-server security patch, whatever it ends up being
vulnerabilityAlerts in the shared preset carries a note that it cannot reach docker-tag
dependencies, so the next reader does not assume it does

Related to #430, but a different claim. #430 is about updates held **forever**. This is about updates held **up to six days**, by design, including for the git server. ## The gap A Forgejo or Postgres image security release cannot bypass the weekly schedule. The shared preset sets `schedule: ["before 6am on monday"]` globally, and exempts security work: ```json "vulnerabilityAlerts": { "minimumReleaseAge": "0 days", "schedule": ["at any time"] } ``` That exemption only reaches updates **Renovate itself classifies** as vulnerability alerts. Both sources of that classification are unavailable here: - **Platform vulnerability alerts.** Renovate reads these from the forge. Forgejo does not provide them, so there are none to read. - **`osvVulnerabilityAlerts: true`.** OSV covers package ecosystems (npm, PyPI, Go, crates and so on). It has no ecosystem for a container image tag. Forgejo and Postgres are tracked by `customManagers` in this repo with `datasource=docker`, matching a `*_image_tag` line in Ansible vars. Renovate has no vulnerability feed for that. So the update is an ordinary scheduled bump, and `vulnerabilityAlerts` never applies to it. Neither this repo's `renovate.json` nor the shared preset gives forgejo or postgres a faster schedule. The only rule naming them is the major gate, which slows them down rather than speeding them up. ## Currently observable `forgejo 16.0.2` is in the Dependency Dashboard's **Awaiting Schedule** section right now, waiting for Monday. Whether 16.0.2 carries security fixes has not been established here and should be checked against the upstream release notes. ## Why this is worth separating from #430 #430's acceptance says the outcome that matters is "a Forgejo **security** update reaching a reviewable PR". Watching 16.0.2 open on Monday proves the `timestamp-required` bug from #430 is fixed. It does not prove security updates arrive promptly, because Monday is exactly when a Monday-scheduled update would open either way. Two different properties, and one observation cannot distinguish them: - **Not held forever.** Fixed, and already evidenced: the entry moved from "Pending Status Checks" to "Awaiting Schedule", and the dashboard now carries the `minimumReleaseAgeBehaviour=timestamp-optional` WARN. - **Arrives promptly when it is security.** Not addressed, and not addressable by anything in the current config. Closing #430 on Monday is correct. It should not be read as closing this. ## Options, not yet chosen 1. **A faster schedule for the two critical images.** A repo-local `packageRule` matching `codeberg.org/forgejo/forgejo` and `docker.io/library/postgres` with a daily rather than weekly window. Simple, and it applies whether or not a given release is security work. Costs a review of ordinary patch bumps up to six days sooner than today. 2. **Watch the upstream security feed directly** and alert, rather than relying on Renovate to classify. Forgejo publishes release announcements; an alert on "deployed tag is behind latest" is independent of Renovate entirely and would also cover the case where Renovate is broken. 3. **Accept and document.** State the six-day worst case as a deliberate trade-off in the runbook so it stops looking like an oversight. Weakest option, but honest, and better than the current state where the config reads as though `vulnerabilityAlerts` covers this. Option 1 is the cheapest real improvement; option 2 is the one that does not depend on Renovate being healthy. They are complementary rather than alternatives. ## Definition of done - [ ] A decision recorded here on which option is taken, with the reasoning - [ ] If a schedule change: shown to work with `platform=local` + `dry-run=full` AND a control run without the rule, since a `matchDepNames` matching nothing looks identical to a rule that works - [ ] The runbook states the worst-case delay for a git-server security patch, whatever it ends up being - [ ] `vulnerabilityAlerts` in the shared preset carries a note that it cannot reach docker-tag dependencies, so the next reader does not assume it does

supernaut lade till etiketterna

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

supernaut lade till detta till projektet Bitborg Infrastructure

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

supernaut refererade till detta ärende

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