-
-
Notifications
You must be signed in to change notification settings - Fork 439
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
Add support for limiting the number of PRs created #3623
Comments
Hi @laeubi This kind of functionality is probably not something I would want to add to the action, but I'm curious what your use case is. Can you explain why the action is creating multiple PRs. I assume you are using the alternative strategy from branch naming? Have you considered using the default strategy and allowing the action to update a single PR until it's merged? |
I have some action that fixes common problem (e.g. resolves a warning or updates a dependency and alike) this created one PR for each problem as it is easier to review and some things might fail in large while work in small. This of course can create a a LOT of PRs and I wanted to make sure not more than 10 are created (e.g. like for dependabot see here). So simply if this action runs and see there are already X PRs open -> act as no changes are there and don't open another. |
I see. I understand what you are trying to do, but I think this is a little bit out of scope for what I would like for this action. I'm trying to keep the action scope contained so that it does one job and does it well! It should be doable to check this in a step before the action runs. If you come up with a solution I would be interested to see it! |
Yes one might can have a step that counts all PRs with the github API and a filter and then use the output from that step in an if-condition. Of course an option in the action would be much more convenient :-D |
I wanted to limit the number of (open) PRs the action can create e.g. not more than 5.
The number of open PRs might be counted by simple pattern matching of branch name, label, username, or whatever seems the easiest here.
The text was updated successfully, but these errors were encountered: