minimumReleaseAge never met for docker python images due often releases

[m-terlinde]

How are you running Renovate?

None

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

43.164.0

Please tell us more about your question or problem

Hello team,

when using the minimumReleaseAge with a docker file, dependencies never get updated with short release cycles.

This is my renovate.json:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "local>devtools/hubcraft/renovate/renovate-config#v1.2.0"
  ],
      "minimumReleaseAge": "7 days"
}

My docker file starts with:
FROM python:3.14-trixie@sha256:10c5cd782d36c531ce712844b404bb2b943cf7562ce5d2a9eede3c5363c0f45d

The Python image gets updated rather frequently:

Thus the MR is never mergable (via auto merge or pipeline check), since the image is updated more often than the minimumReleaseAge value.

Is this something that can be configured? I would expect Renovate to not update this MR with newer versions and instead push one, wait the minimumReleaseAge, wait for merge and then start again.
If the MR is open for a long time, Renovate could update the MR to a version that honours the minimumReleaseAge instead of the newest.

Any thoughts on that?

Cheers,
Matthias

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[sueun-dev]

This looks mostly expected. minimumReleaseAge isn't a "wait until the image stops changing for 7 days" setting. Renovate checks it per release/digest, and the docs call that out pretty directly.

So for a fast-moving tag like python:3.14-trixie, an existing PR can keep getting updated as newer eligible digests roll through. That matches the example in the minimum-release-age docs where an open PR gets bumped again once the next version passes the age check.

The knob I'd use here is a schedule on that Docker image, not just minimumReleaseAge, e.g. weekly for python Dockerfile updates. internalChecksFilter is already strict by default in 43.x, unless your inherited config overrides it.

Small caveat: your example is digest-pinned, and Renovate's docs mark digest support for minimumReleaseAge as partial / datasource-dependent, so I'd keep an eye on the logs for whether Renovate has a releaseTimestamp for that Docker update.

[m-terlinde]

Thanks for your reply!
You are right, Renovate should not wait for less frequent changes than 7 days.
But I would expect that it checks, that an "older" release satisfies the minimumReleaseAge and merge that one.

How would that schedule look like?

Is that the correct way?

{
  "packageRules": [
    {
      "description": "Schedule docker python updates weekly",
      "matchPackageNames": ["python:*"],
      "schedule": ["0 0 * * 1"]
    }
  ]
}

[sueun-dev]

yep, your expectation is basically right for normal version updates: Renovate can use an older release once that specific release has passed minimumReleaseAge.

The catch here is the digest-pinned Docker image. For Docker digests, minimumReleaseAge support is still partial / datasource-dependent, so I wouldn’t rely on that alone to stop this PR from getting refreshed all the time.

Your schedule idea is close, but I’d tweak it like this:

{
  "packageRules": [
    {
      "description": "Schedule Docker Python image updates weekly",
      "matchManagers": ["dockerfile"],
      "matchDatasources": ["docker"],
      "matchPackageNames": ["python"],
      "matchCurrentValue": "3.14-trixie",
      "schedule": ["* 0-3 * * 1"],
      "updateNotScheduled": false
    }
  ]
}

python:* won’t match here. Renovate sees the package as python; the tag is the current value, 3.14-trixie.

Also, 0 0 * * 1 is too exact for Renovate cron schedules. The minutes field needs to be *, so * 0-3 * * 1 gives Renovate a Monday 00:00-03:59 window. Add timezone if you don’t want that interpreted in the bot’s default timezone.

[m-terlinde]

Thanks a lot for that, will try that next week!

One think regarding digest-pinning: that was also done by the Renovate bot automatically.
It wouldn't make any sense to disable that again, right? Otherwise Renovate wouldn't have anything to update and it would render the release age constraint against supply chain attacks useless, right?

Oh and would that behaviour I wanted/expected in my first post be something for a feature request?