ci: confirm the release-age quarantine releases docker-datasource updates #332

Nytt ärende

Stängd

öppnade 2026-08-02 12:30:47 +00:00 av supernaut · 1 kommentar

supernaut kommenterad

2026-08-02 12:30:47 +00:00

Ägare

minimumReleaseAge needs a release timestamp from the datasource. Under
internalChecksFilter: "strict" (Renovate's default) an update whose timestamp cannot be determined
is withheld indefinitely, not for the configured window — silently, and reported under
Pending Status Checks on the Dependency Dashboard with no branch pushed and no error logged.

Since 2026-07-31, update node.js to v24.18.1 for docker.io/library/node
(24.18.0-trixie-slim → 24.18.1-trixie-slim) has been held in that state in two repos, while the
npm/Volta bump to the same version merged on 2026-07-30 (#251, #55). The expected release from
quarantine is the 2026-08-03 nightly run.

Verify: after the 2026-08-03 00:30 run, check whether the PR was opened. If it was, close this —
the quarantine works and the delay was arithmetic. If node 24.18.1 is still pending, docker-tag
updates are permanently stuck behind the quarantine and need an explicit exemption:

{ "matchDatasources": ["docker"], "minimumReleaseAge": "0 days" }

Acceptance: either this issue is closed with evidence of the PR, or the preset carries an
exemption and a docker-tag update lands on the following run.

`minimumReleaseAge` needs a release timestamp from the datasource. Under `internalChecksFilter: "strict"` (Renovate's default) an update whose timestamp cannot be determined is withheld **indefinitely**, not for the configured window — silently, and reported under `Pending Status Checks` on the Dependency Dashboard with no branch pushed and no error logged. Since 2026-07-31, `update node.js to v24.18.1` for `docker.io/library/node` (`24.18.0-trixie-slim` → `24.18.1-trixie-slim`) has been held in that state in two repos, while the npm/Volta bump to the same version merged on 2026-07-30 (#251, #55). The expected release from quarantine is the 2026-08-03 nightly run. **Verify:** after the 2026-08-03 00:30 run, check whether the PR was opened. If it was, close this — the quarantine works and the delay was arithmetic. If node 24.18.1 is still pending, docker-tag updates are permanently stuck behind the quarantine and need an explicit exemption: ```json { "matchDatasources": ["docker"], "minimumReleaseAge": "0 days" } ``` **Acceptance:** either this issue is closed with evidence of the PR, or the preset carries an exemption and a docker-tag update lands on the following run.

supernaut lade till etiketterna

2026-08-02 12:31:42 +00:00

supernaut lade till detta till projektet Bitborg Infrastructure

2026-08-02 12:34:55 +00:00

supernaut refererade till detta ärende från en incheckning

2026-08-18 05:06:50 +00:00

fix(renovate): stop the docker datasource stalling in Pending Status Checks

supernaut refererade till detta ärende från bitborg/bitborg-docs

2026-08-18 05:07:22 +00:00

fix(renovate): stop the docker datasource stalling in Pending Status Checks #91

supernaut refererade till detta ärende

2026-08-18 05:08:07 +00:00

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

supernaut kommenterad

2026-08-18 05:08:23 +00:00

Upphovsperson

Ägare

Answered, and the answer is no: the release-age quarantine does not release docker-datasource
updates. It never releases them at all.

minimumReleaseAgeBehaviour defaults to timestamp-required, and Renovate's docker datasource often
returns no releaseTimestamp. A check that needs a timestamp can never pass without one, so the
update is deferred on every run and no branch is ever created. It sits in the Dependency Dashboard's
"Pending Status Checks" section indefinitely.

Measured 2026-08-17 on this repo: seven image updates held that way, including the git server
(16.0.2, 18 days old) and the database. Reproduced at debug on renovate 43.288.0, the version
production runs, with no production access and no apply. Full write-up in #430.

The suspicion in this issue was correct, and it was worth filing. What made it hard to confirm is
that release age looks satisfied from the registry side: Renovate never compares ages when the
timestamp is absent, so the dates prove nothing either way.

Fix: bitborg/bitborg-docs#91, one packageRule scoped to matchDatasources: ["docker"] setting
minimumReleaseAgeBehaviour: "timestamp-optional". Verified to take all seven from held to
branch-intent. The preset is resolved from main at run time, so merging is the whole deployment.

Closing this in favour of #430, which carries the root cause, the verification and the follow-ups.

Answered, and the answer is **no**: the release-age quarantine does **not** release docker-datasource updates. It never releases them at all. `minimumReleaseAgeBehaviour` defaults to `timestamp-required`, and Renovate's docker datasource often returns no `releaseTimestamp`. A check that needs a timestamp can never pass without one, so the update is deferred on every run and no branch is ever created. It sits in the Dependency Dashboard's "Pending Status Checks" section indefinitely. Measured 2026-08-17 on this repo: seven image updates held that way, including the git server (16.0.2, 18 days old) and the database. Reproduced at debug on renovate 43.288.0, the version production runs, with no production access and no apply. Full write-up in #430. The suspicion in this issue was correct, and it was worth filing. What made it hard to confirm is that release age looks satisfied from the registry side: Renovate never compares ages when the timestamp is absent, so the dates prove nothing either way. Fix: bitborg/bitborg-docs#91, one `packageRule` scoped to `matchDatasources: ["docker"]` setting `minimumReleaseAgeBehaviour: "timestamp-optional"`. Verified to take all seven from held to branch-intent. The preset is resolved from `main` at run time, so merging is the whole deployment. Closing this in favour of #430, which carries the root cause, the verification and the follow-ups.

supernaut refererade till detta ärende från en incheckning

2026-08-18 09:04:03 +00:00

fix(renovate): stop the docker datasource stalling in Pending Status Checks (#91)

supernaut stängde ärendet

2026-08-18 09:06:38 +00:00

supernaut refererade till detta ärende

2026-09-20 00:03:27 +00:00

renovate: six updates stuck in awaiting_schedule for 22-32 days, never becoming PRs #487

supernaut refererade till detta ärende från en incheckning

2026-10-02 17:57:00 +00:00

fix(renovate): stop the docker datasource stalling in Pending Status Checks (#91)

Logga in för att delta i denna konversation.