Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

docs(configuration options): rewrite minimumReleaseAge #29570

Merged
merged 3 commits into from
Jun 21, 2024
Merged

docs(configuration options): rewrite minimumReleaseAge #29570

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e3bbc3d
docs(configuration options): rewrite minimumReleaseAge
HonkingGoose Jun 10, 2024
3fa03fa
Update docs/usage/configuration-options.md
HonkingGoose Jun 11, 2024
685b391
Merge branch 'main' into docs/rewrite-minimumReleaseAge
HonkingGoose Jun 21, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 20 additions & 15 deletions docs/usage/configuration-options.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2270,38 +2270,41 @@ Renovate will only add a milestone when it _creates_ the PR.

This feature used to be called `stabilityDays`.

If this is set _and_ an update has a release timestamp header, then Renovate will check if the set duration has passed.
If `minimumReleaseAge` is set to a number value _and_ the update has a release timestamp header, then Renovate will check if the set duration has passed.
HonkingGoose marked this conversation as resolved.
Show resolved Hide resolved

Note: Renovate will wait for the set duration to pass for each **separate** version.
Renovate does not wait until the package has seen no releases for x time-duration(`minimumReleaseAge`).
`minimumReleaseAge` is not intended to help with slowing down fast releasing project updates.
If you want to slow down PRs for a specific package, setup a custom schedule for that package.
Read [our selective-scheduling help](./noise-reduction.md#selective-scheduling) to learn how to set the schedule.

If the time since the release is less than the set `minimumReleaseAge` a "pending" status check is added to the branch.
If enough days have passed then the "pending" status is removed, and a "passing" status check is added.
Do _not_ use `minimumReleaseAge` to slow down fast releasing project updates.
Instead setup a custom `schedule` for that package, read [our selective-scheduling help](./noise-reduction.md#selective-scheduling) to learn how.

Some datasources don't have a release timestamp, in which case this feature is not compatible.
Other datasources may have a release timestamp, but Renovate does not support it yet, in which case a feature request needs to be implemented.
When the time passed since the release is _less_ than the set `minimumReleaseAge`: Renovate adds a "pending" status check to that update's branch.
After enough days have passed: Renovate replaces the "pending" status with a "passing" status check.

Maven users: you cannot use `minimumReleaseAge` if a Maven source returns unreliable `last-modified` headers.
The datasource that Renovate uses must have a release timestamp for the `minimumReleaseAge` config option to work.
Some datasources may have a release timestamp, but in a format that's Renovate does not support.
In those cases a feature request needs to be implemented.

<!-- prettier-ignore -->
!!! warning "Warning for Maven users"
For `minimumReleaseAge` to work, the Maven source must return reliable `last-modified` headers.

<!-- prettier-ignore -->
!!! note
Configuring this option will add a `renovate/stability-days` option to the status checks.

There are a couple of uses for `minimumReleaseAge`:
Examples of how you can use `minimumReleaseAge`:

<!-- markdownlint-disable MD001 -->

#### Suppress branch/PR creation for X days

If you combine `minimumReleaseAge=3 days` and `internalChecksFilter="strict"` then Renovate will hold back from creating branches until 3 or more days have elapsed since the version was released.
We recommend that you set `dependencyDashboard=true` so you can see these pending PRs.
If you use `minimumReleaseAge=3 days` and `internalChecksFilter="strict"` then Renovate only creates branches when 3 (or more days) have passed since the version was released.
We recommend you set `dependencyDashboard=true`, so you can see these pending PRs.

#### Prevent holding broken npm packages

npm packages less than 72 hours (3 days) old can be unpublished, which could result in a service impact if you have already updated to it.
npm packages less than 72 hours (3 days) old can be unpublished from the npm registry, which could result in a service impact if you have already updated to it.
Set `minimumReleaseAge` to `3 days` for npm packages to prevent relying on a package that can be removed from the registry:

```json
Expand All @@ -2317,8 +2320,10 @@ Set `minimumReleaseAge` to `3 days` for npm packages to prevent relying on a pac

#### Await X time duration before Automerging

If you enabled `automerge` _and_ `minimumReleaseAge`, it means that PRs will be created immediately but automerging will be delayed until the time-duration has passed.
This works because Renovate will add a "renovate/stability-days" pending status check to each branch/PR and that pending check will prevent the branch going green to automerge.
If you enable `automerge` _and_ `minimumReleaseAge`, Renovate will create PRs immediately, but only automerge them when the `minimumReleaseAge` time-duration has passed.

Renovate adds a "renovate/stability-days" pending status check to each branch/PR.
This pending check prevents the branch going green to automerge before the time has passed.

<!-- markdownlint-enable MD001 -->

Expand Down