[gklein]

Summary

Hold OpenShell release bumps for 2 days so Renovate never proposes a release that upstream pulls shortly after publishing. That happened with #3967: CI failed on a 404 for the release checksums, and the PR had to be closed by hand.

Related Issue

Closes #4076

Changes

• renovate.json: add minimumReleaseAge: "2 days" to the openshell group rule.
• Add minimumReleaseAgeBehaviour: "timestamp-optional" to the same rule. This is required. The group also covers the base image, which is digest-pinned on ghcr:
  • Renovate 44 age-checks digest updates too (lib/workers/repository/process/lookup/digest.ts).
  • The Docker datasource only gets release dates from Docker Hub (lib/modules/datasource/docker/index.ts). ghcr's tag list returns only name and tags, with no dates.
  • So under the default timestamp-required, every base-image update would be held forever. With timestamp-optional, the base image flows as it does today, and the version pin, which has a GitHub release date, is still held for 2 days.

Behaviour in Renovate 44 (from source):

• With the default internalChecksFilter: strict, a release younger than the window creates no branch, no PR and no CI run (lib/workers/repository/update/branch/index.ts). It shows as pending on the Dependency Dashboard (Dependency Dashboard #2682) and opens as a normal PR once it is 2 days old.
• An existing renovate/openshell branch is not rebased onto a release that is still inside the window.
• The hold only delays when Renovate opens the PR. An urgent release can still be merged early through a regular PR that bumps the version.

Known limits:

• A release pulled after the 2-day window still fails CI. The window narrows the risk; it doesn't remove it.
• If GitHub ever returned an OpenShell release without a date, timestamp-optional would let it through without the hold.

Drops releases that upstream yanks within the window. It does not change how often the OpenShell PR is opened or rebased, so it does not help with #7837.

Testing

• pre-commit run --files renovate.json passes (check json, whitespace, secrets)
• renovate-config-validator (Renovate 44) reports Config validated successfully
• After merge: the next OpenShell release shows as pending on Dependency Dashboard #2682 for 2 days, then opens a PR

Checklist

• PR title follows Conventional Commits (correct type, ! for breaking changes)
• Commits are signed off (DCO)
• I wrote this contribution myself and can explain all changes in it

🤖 Generated with Claude Code

[github-actions]

E2E tests did not run

E2E tests run automatically for org/repo members and collaborators on pull requests.

For other contributors, a maintainer with write access must add the ok-to-test label after the latest push.

See E2E testing guide for details.

[github-actions]

E2E tests did not run

E2E tests run automatically for org/repo members and collaborators on pull requests.

For other contributors, a maintainer with write access must add the ok-to-test label after the latest push.

See E2E testing guide for details.

[qodo-code-review]

PR Summary by Qodo

Delay OpenShell Renovate updates for two days

⚙️ Configuration changes 🐞 Bug fix 🕐 Less than 10 minutes

AI Description

• Hold dated OpenShell releases for two days before Renovate proposes an update.
• Allow undated GHCR base-image digest updates to continue instead of blocking them indefinitely.

Diagram

graph TD
  GH["GitHub version"] --> Age{"2 days old?"} -->|Yes| PR["OpenShell PR"]
  Image["GHCR digest"] --> Optional{"Timestamp optional?"} -->|Yes| PR

Loading

High-Level Assessment

Keep the age check in the existing OpenShell group rule. Separate rules could apply different timestamp policies, but would complicate a group that intentionally combines the version pin and base image; the optional policy preserves digest updates while delaying dated releases.

Files changed (1) +3 / -1

Other (1) +3 / -1

renovate.jsonAdd a two-day age check to the OpenShell group +3/-1

Add a two-day age check to the OpenShell group

• Adds a two-day minimum release age to reduce PRs for releases pulled shortly after publication. Sets timestamp-optional behavior so the digest-pinned GHCR base image is not blocked for lacking release dates, and documents the distinction in the rule.

renovate.json

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can tweak Display settings with a live preview to see your comment before it ships

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[waynesun09]

MEDIUM: the PR body says the hold reduces OpenShell PR churn (#7837), but it doesn't

This is about the PR description, not renovate.json. The Changes section says: "back-to-back releases inside the window produce one PR instead of several."

Renovate 44 doesn't work that way. filterInternalChecks() in lib/workers/repository/process/lookup/filter-checks.ts loops over sortedReleases.reverse(), so it checks releases from newest to oldest and picks the first one that has passed minimumReleaseAge:

• If v0.1.4 is 2 days old and v0.1.5 is still pending, Renovate opens or updates renovate/openshell for v0.1.4.
• When v0.1.5 reaches 2 days, Renovate updates the same branch again.

The hold delays every release by the same amount, so the number of branch updates stays the same, and so do the CI and review runs they trigger. Two releases only collapse into one update when both become eligible between the same two Renovate runs. That also happens without the hold. The #7837 example (#7763, v0.1.0 to v0.1.2 over about 2 weeks) is also much longer than a 2-day window.

Suggestion: remove the #7837 sentence, or change it to something like: "Drops releases that are yanked within the window. It does not change how often the OpenShell PR is opened or rebased." #7837 needs its own fix, for example Dependency Dashboard approval mode, or pausing the group while a migration PR is open.

[gklein]

@waynesun09 Thanks, you're right. filterInternalChecks() picks the newest release that has passed the window, so each release still lands as its own branch update, just 2 days later. The hold only drops releases that upstream yanks within the window. I've updated the PR description to say that and removed the #7837 churn claim.