You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As I understand, git-xargs works for following way:
clones all passed repos
runs the command on all repos
pushes all changed repos to remote
opens all PRs
Our main branches require successful workflow-runs for merging. So I should use the --no-skip-ci option. But this would mean, that I start over hundred workflow-runs in a few seconds. This would block our runners for hours.
Instead I don't use the --no-skip-ci option and run a script afterwards which does an empty commit to each repository to trigger the workflow and wait some time.
Describe the solution you'd like
My prefered solution would be, if git-xargs runs the steps 1-4 per repo and then waits some configurable time before repeating steps 1-4 with the next repository.
This way I the wait time will be used to wait for runners to complete and for the rate limit to go down.
In my case most of the execution time is wasted for waiting. This way, it could be decreased.
Describe alternatives you've considered
Additional parameter to configure wait time between pushes.
The text was updated successfully, but these errors were encountered:
I maintain a similar project called multi-gitter that would support this usecase. It has no flag to wait between runs, but run 1,2,3 and 4 in sequence for each repo, before proceeding to the next one (if parallel mode is not chosen). So adding a wait in the command step should produce the result you want.
As I understand, git-xargs works for following way:
Our main branches require successful workflow-runs for merging. So I should use the --no-skip-ci option. But this would mean, that I start over hundred workflow-runs in a few seconds. This would block our runners for hours.
Instead I don't use the --no-skip-ci option and run a script afterwards which does an empty commit to each repository to trigger the workflow and wait some time.
Describe the solution you'd like
My prefered solution would be, if git-xargs runs the steps 1-4 per repo and then waits some configurable time before repeating steps 1-4 with the next repository.
This way I the wait time will be used to wait for runners to complete and for the rate limit to go down.
In my case most of the execution time is wasted for waiting. This way, it could be decreased.
Describe alternatives you've considered
Additional parameter to configure wait time between pushes.
The text was updated successfully, but these errors were encountered: