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.

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

feat: baseBranchStalenessThreshold #33986

Open
rarkins opened this issue Feb 1, 2025 · 0 comments
Open

feat: baseBranchStalenessThreshold #33986

rarkins opened this issue Feb 1, 2025 · 0 comments
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:feature Feature (new functionality)

Comments

@rarkins
Copy link
Collaborator

rarkins commented Feb 1, 2025

Discussed in #33985

Originally posted by Alicipy February 1, 2025

Tell us more.

Hello,

I am working with some projects that have their last commit on the default branch from months ago, as we right now don't use them or have them not deployed. Right now, renovate tries to update them too, leading to a lot of PRs. We thought about archiving them, but hten they are not visible anymore, or we know that at 'some point' we will actively work with them again.

For that, I wanna suggest to have a flag for Renovate that only opens up new PRs or even closes existing ones when the last commit on the default branch is older than a time limit. This way, as soon as the repo is active again, also PRs would come in from Renovate, but as long as it is not touched, it stays there but in an unupdated state.

I would like your thoughts about that, if this is a good idea or you have other ideas or suggestions.
In case it is appreciated and wanted, I would take care of implementing this feature.

Proposal:

  • New config option baseBranchStalenessThreshold
  • Same syntax as minimumReleaseAge
  • Evaluated per-base branch
  • If a base branch commit is older than the threshold then we skip it and log an INFO message "Base branch skipped due to exceeding staleness threshold"
  • Must work efficiency with repository cache to avoid cloning
@rarkins rarkins added priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:feature Feature (new functionality) labels Feb 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:feature Feature (new functionality)
Projects
None yet
Development

No branches or pull requests

1 participant