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

New Parameter: wait time between pushes #110

Open
radicarl opened this issue Jan 19, 2023 · 1 comment
Open

New Parameter: wait time between pushes #110

radicarl opened this issue Jan 19, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@radicarl
Copy link

As I understand, git-xargs works for following way:

  1. clones all passed repos
  2. runs the command on all repos
  3. pushes all changed repos to remote
  4. 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.

@radicarl radicarl added the enhancement New feature or request label Jan 19, 2023
@lindell
Copy link

lindell commented Nov 9, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants