prStalenessThreshold

[rarkins]

As discussed with @felipecrs in #34012

Add a new configuration option prStalenessThreshold. It should support a duration string with same supported syntax as minimumReleaseAge, e.g. "90 days". It should default to null to retain backwards-compatible behavior, although in future we may choose to give it a non-null default in a new major release.

The behavior should be like this:

• prStalenessThreshold can be configured in packageRules, even down to per-package or update type if users wish
• A branch's prStalenessThreshold will be null if all updates within it are null, otherwise it will be the largest of the non-null values
• If a branch has a prStalenessThreshold defined, and it hasn't been exceeded yet (calculated as "current timestamp minus PR creation timestamp"), then there's no change of behavior
• If a branch has a prStalenessThreshold defined, and it has been exceeded, then no rebasing or updating (e.g. if a newer version is available) will be done automatically
• Calculation of staleness should be done post-branchifying and before branch processing
  • Each update should have isStale=true if a prStalenessThreshold exists and is exceeded, isStale=false if a prStalenessThreshold exists and is not exceeded, and no isStale field if no prStalenessThreshold is defined
  • A branch should have no isStale field if no updates have an isStale field, it should have isStale=false if any update has isStale=false, and it should have isStale=true otherwise (i.e. which means if all isStale fields in updates are true)
• During branch processing, rebasing/updating will be done only if manually triggered by a user (e.g. checkbox or label in PR, or checkbox in Dependency Dashboard)
• Dependency Dashboard should add new category "Stale" to go below "Open", and PRs which have exceeded it are grouped there instead of Open. It should use the same logic as the branch.isStale described above

[felipecrs]

Fantastic. Maybe you should also mention something like Stale PRs should not be counted towards the prConcurrentLimit.

[rarkins]

I don't think that's a good default behavior, but instead could be configurable

[felipecrs]

Oh ok. We can keep that as a separate, later improvement then.