v0.1.1

Modules affected

Description

• Fix --skip-pull-requests behavior

Related links

• #86

v0.1.0

Modules affected

Description

• Prepend [skip ci] to commit messages by default
• Fix concurrency bug(s)
• Prettify run report with pterm.sh tables / styles

Migration guide

• The --max-concurrent-repos flag has been removed. Please update any earlier git-xargs invocations / scripts that use that flag to remove it.
• By default, git-xargs will now prepend [skip ci] to all commit messages, unless you pass the new --no-skip-ci flag. This feature is intended to prevent large git-xargs jobs from causing excessively costly continuous integration (CI) jobs.

Related links

• #89
• #85
• #84

v0.0.16

Description

• Updated the PR template so you get a nice little form.
• Updated codeowners so that more people are notified.
• Updated the table outputs to be markdown friendly. This replaces the pipe | and dash - symbols in the printed output.

Related links

• #73
• #76
• #78

v0.0.15

Description

This release brings git-xargs functionality in line with GitHub's API recommendations for integrators regarding rate limits.. This means that git-xargs now respects GitHub API rate limits and reacts to related header values that GitHub may send when rate limiting a client, in order to intelligently slow down and stagger open pull request API calls.

To further assist in running rate-limit-compliant jobs, git-xargs now features two separate processing channels for two types of work:

1. Work that can be performed in parallel as quickly as possible
2. Work that needs to be treated sensitively in observance of rate limits (such as making open pull request API calls to GitHub)

Work that can be performed in parallel is still done as quickly as possible. Pull requests API calls that are generated by a git-xargs run are now staggered and opened serially at the end of a run. In addition, open pull request API calls that fail due to rate limiting are now automatically retried, with configurable back-off behavior.

In addition, new flags have been added to assist with configuring your git-xargs jobs so that they do not trip GitHub rate limits.

Please see the new section of the git-xargs README titled "Rate Limiting" for more information.

Related links

• #67

v0.0.14

Description

• Support for overriding base branch names. Adds a new optional --base-branch-name flag. Pass this flag to override the base branch to target pull requests against for all repositories in a given run of git-xargs.

Special thanks

Special thanks to the following users for their contribution!

• @nirnanaaa

Related links

• #64

v0.0.13

Modules affected

Description

• Add script to add PR & Issue templates to all IaC repos
• Add GitHub PR & Issue Templates
• Update the script for Adding/Updating PR & Issue Templates
• feat: Add --draft flag for draft pull requests. You can now pass the --draft flag to open Draft pull requests against those Github repos that support this functionality.

Special thanks

Special thanks to the following users for their contribution!

• @ryanwholey

Related links

• #58
• #57
• #60
• #49

v0.0.12

Modules affected

Description

• Document use of --loglevel flag
• Add pre-commit config and include goimports
• Fix docs and comments
• Repo selection mode and error handling enhancements

Related links

• #45
• #52
• #51
• #54

v0.0.11

Modules affected

Description

• Docs update: Note that git-xargs performs work in parallel
• Docs update: add homebrew install instruction

Special thanks

Special thanks to the following users for their contribution!

• @chenrui333

Related links

• #46
• #44

v0.0.10

Modules affected

Description

Improve logging by moving git operations progress to DEBUG level

• This also adds an INFO message every time a repository has been successfully processed giving the end user a meaningful default progress output at the INFO level without flooding stdout with the git operation progress output (Which is now still accessible through the DEBUG log level)

• Fix a few typos in README

• Move log for untracked file into debug level logger

Special thanks

Special thanks to the following users for their contribution!

• @jphuynh

Related links

• #40

v0.0.9

Modules affected

Description

• Feature: Optionally limit the number of concurrent go routines via SizedWaitGroup. There is a new optional flag --max-concurrent-repos that accepts an int which will determine the number of goroutines that can be run simultaneously to process repos.

You can use this flag to set a limit on processing concurrency if you are running into performance issues when running git-xargs on many (hundreds or more) repos simultaneously.

If you do not pass this flag, the default behavior is for the number of goroutines that can be started simultaneously to remain unlimited (1 goroutine is started for each repo you need to process given your selection criteria).

Special thanks

Special thanks to the following users for their contribution!

• @jphuynh

Related links

• #38