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

Evaluate pr/branch limits per-branch #32133

Closed
rarkins opened this issue Oct 25, 2024 · 4 comments · Fixed by #32556
Closed

Evaluate pr/branch limits per-branch #32133

rarkins opened this issue Oct 25, 2024 · 4 comments · Fixed by #32556
Assignees
Labels
priority-2-high Bugs impacting wide number of users or very important features type:feature Feature (new functionality)

Comments

@rarkins
Copy link
Collaborator

rarkins commented Oct 25, 2024

Describe the proposed change(s).

Current, limit are calculated prior to branch execution:

const prsRemaining = await getPrsRemaining(config, branches);
logger.debug(`Calculated maximum PRs remaining this run: ${prsRemaining}`);
setMaxLimit('PullRequests', prsRemaining);
const branchesRemaining = await getBranchesRemaining(config, branches);
logger.debug(
`Calculated maximum branches remaining this run: ${branchesRemaining}`,
);
setMaxLimit('Branches', branchesRemaining);

And evaluated within branch execution such as

if (
!branchExists &&
isLimitReached('Branches') &&
!dependencyDashboardCheck &&
!config.isVulnerabilityAlert
) {
logger.debug('Reached branch limit - skipping branch creation');
return {
branchExists,
prNo: branchPr?.number,
result: 'branch-limit-reached',
};
}

Much of the logic is also inside https://github.com/renovatebot/renovate/blob/main/lib/workers/repository/process/limits.ts

Instead of having global limits as today, we should instead allow separate limits per-branch, and evaluate those limits per-branch instead. This means removing these global limit settings:

And instead passing the relevant limit like prBranchLimit and prConcurrentLimit through to the "is limit reached?" functions.

Ideally the point in our workers where these limits are evaluated is kept the same as today so that there is "less changes" and risk of breaking things. And so the change is that the limits are passed through rather than used globally.

Note: commits will still be global

@rarkins rarkins added type:feature Feature (new functionality) priority-2-high Bugs impacting wide number of users or very important features labels Oct 25, 2024
@rarkins rarkins self-assigned this Oct 25, 2024
@rarkins
Copy link
Collaborator Author

rarkins commented Oct 25, 2024

I've begun initial refactorings for this in https://github.com/renovatebot/renovate/compare/feat/per-branch-limits?expand=1

@RahulGautamSingh
Copy link
Collaborator

RahulGautamSingh commented Dec 5, 2024

Duplicate: #10546

@rarkins
Copy link
Collaborator Author

rarkins commented Dec 5, 2024

Different actually. I wanted the first work to be evaluating per branch. Second work is allowing multiple groups per branch

@rarkins rarkins added type:feature Feature (new functionality) and removed type:feature Feature (new functionality) labels Jan 19, 2025
@renovate-release
Copy link
Collaborator

🎉 This issue has been resolved in version 39.119.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-2-high Bugs impacting wide number of users or very important features type:feature Feature (new functionality)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants