I think our renovate config may be overly restrictive, to the point that we're not promptly getting the PRs we'd like to be getting. Possibly this is an unintended consequence of the minimumReleaseAge changes. I noticed this because there hadn't been a CTS update PR for several weeks. On Friday I manually requested a CTS update in the renovate UI.
I am not sure if this is a configuration error on our part, bugs in renovate, or some combination.
Here are some excerpts from the log for https://developer.mend.io/github/gfx-rs/wgpu/-/job/019f58d8-dbad-7a10-979f-9b4b94127acf, which completed July 13, 1:59:49 UTC.
2026-07-13T01:58:48.917Z [renovate/cts-digest] Checking schedule(schedule=* 0-3 * * 1, tz=null, now=2026-07-13T01:58:48.917Z)
2026-07-13T01:58:48.921Z [renovate/cts-digest] Checking 1 schedule(s)
2026-07-13T01:58:48.925Z [renovate/cts-digest] Human-readable summary for cron:: Every minute, between 12:00 AM and 03:59 AM, only on Monday
2026-07-13T01:58:48.927Z [renovate/cts-digest] Matches schedule * 0-3 * * 1
... a few more that report they match the schedule, then:
2026-07-13T01:59:45.536Z [renovate/bit-vec-0.x] Checking schedule(schedule=* 0-3 * * 1, tz=null, now=2026-07-13T01:59:45.536Z)
2026-07-13T01:59:45.537Z [renovate/bit-vec-0.x] Checking 1 schedule(s)
2026-07-13T01:59:45.538Z [renovate/bit-vec-0.x] Human-readable summary for cron:: Every minute, between 12:00 AM and 03:59 AM, only on Monday
2026-07-13T01:59:45.539Z [renovate/bit-vec-0.x] Package not scheduled
2026-07-13T01:59:45.539Z [renovate/bit-vec-0.x] Skipping branch creation as not within schedule
It's only one minute later, but now doesn't match the schedule? I'm also unsure in general if the four hour window is sufficient. It seems like for updates to happen, renovate may need to run twice within the window, once to create the branch, and a second time to see that checks have passed and to actually create the PR?
And it appears some/all Rust crates may not have the release timestamps necessary to support minimumReleaseAge:
2026-07-13T01:59:45.866Z [renovate/Cargo.lock-update] Checking schedule(schedule=before 4am on monday, tz=null, now=2026-07-13T01:59:45.866Z)
2026-07-13T01:59:45.869Z [renovate/Cargo.lock-update] Checking 1 schedule(s)
2026-07-13T01:59:45.870Z [renovate/Cargo.lock-update] Checking schedule "before 4am on monday"
2026-07-13T01:59:45.872Z [renovate/Cargo.lock-update] Matches schedule before 4am on monday
2026-07-13T01:59:45.873Z [renovate/Cargo.lock-update] Marking 26 release(s) as pending, as they do not have a releaseTimestamp and we're running with minimumReleaseAgeBehaviour=timestamp-required
The easiest thing to do here may be to give up on minimumReleaseAge and roll back all the related changes.
I think our renovate config may be overly restrictive, to the point that we're not promptly getting the PRs we'd like to be getting. Possibly this is an unintended consequence of the
minimumReleaseAgechanges. I noticed this because there hadn't been a CTS update PR for several weeks. On Friday I manually requested a CTS update in the renovate UI.I am not sure if this is a configuration error on our part, bugs in renovate, or some combination.
Here are some excerpts from the log for https://developer.mend.io/github/gfx-rs/wgpu/-/job/019f58d8-dbad-7a10-979f-9b4b94127acf, which completed July 13, 1:59:49 UTC.
... a few more that report they match the schedule, then:
It's only one minute later, but now doesn't match the schedule? I'm also unsure in general if the four hour window is sufficient. It seems like for updates to happen, renovate may need to run twice within the window, once to create the branch, and a second time to see that checks have passed and to actually create the PR?
And it appears some/all Rust crates may not have the release timestamps necessary to support
minimumReleaseAge:The easiest thing to do here may be to give up on
minimumReleaseAgeand roll back all the related changes.