Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/lindell/multi-gitter

Update multiple repositories in with one command
https://github.com/lindell/multi-gitter

automation cli commandline developer-tools devops devtools git github gitlab go golang productivity script

Last synced: 24 days ago
JSON representation

Update multiple repositories in with one command

Host: GitHub
URL: https://github.com/lindell/multi-gitter
Owner: lindell
License: apache-2.0
Created: 2020-05-18T06:09:40.000Z (over 4 years ago)
Default Branch: master
Last Pushed: 2024-09-16T18:08:23.000Z (about 2 months ago)
Last Synced: 2024-09-30T03:04:53.483Z (about 1 month ago)
Topics: automation, cli, commandline, developer-tools, devops, devtools, git, github, gitlab, go, golang, productivity, script
Language: Go
Homepage:
Size: 1.67 MB
Stars: 864
Watchers: 7
Forks: 64
Open Issues: 34
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
- Code of conduct: CODE_OF_CONDUCT.md
- Codeowners: .github/CODEOWNERS
- Security: SECURITY.md

Awesome Lists containing this project

awesome-git - multi-gitter - a tool to make changes in multiple repositories simultaneously (Tools / Comparing workflows)

README

*multi-gitter* allows you to make changes in multiple repositories simultaneously. This is achieved by running a script or program in the context of multiple repositories. If any changes are made, a pull request is created that can be merged manually by the set reviewers, or automatically by multi-gitter when CI pipelines have completed successfully.

Are you a bash-guru or simply prefer your scripting in Node.js? It doesn't matter, since multi-gitter support any type of script or program. **If you can script it to run in one place, you can run it in all your repositories with one command!**

### Some examples:
* Syncing a file (like a PR-template)
* Programmatic refactoring
* Updating a dependency
* Automatically fixing linting issues
* Search and replace
* Anything else you are able to script!

## Demo

![Gif](docs/img/demo.gif)

## Example

### Run with file
```bash
$ multi-gitter run ./my-script.sh -O my-org -m "Commit message" -B branch-name
```

Make sure the script has execution permissions before running it (`chmod +x ./my-script.sh`)

### Run code through interpreter
If you are running an interpreted language or similar, it's important to specify the path as an absolute value (since the script will be run in the context of each repository). Using the `$PWD` variable helps with this.
```bash
$ multi-gitter run "python $PWD/run.py" -O my-org -m "Commit message" -B branch-name
$ multi-gitter run "node $PWD/script.js" -R repo1 -R repo2 -m "Commit message" -B branch-name
$ multi-gitter run "go run $PWD/main.go" -U my-user -m "Commit message" -B branch-name
```

### Test before live run
You might want to test your changes before creating commits. The `--dry-run` flag provides an easy way to test without actually making any modifications. It works well when setting the log level to `debug`, with `--log-level=debug`, to also print the changes that would have been made.
```
$ multi-gitter run ./script.sh --dry-run --log-level=debug -O my-org -m "Commit message" -B branch-name
```

## Install

### Homebrew
If you are using Mac or Linux, [Homebrew](https://brew.sh/) is an easy way of installing multi-gitter.
```bash
brew install lindell/multi-gitter/multi-gitter
```

### Manual binary install
Find the binary for your operating system from the [release page](https://github.com/lindell/multi-gitter/releases) and download it.

### Automatic binary install
To automatically install the latest version
```bash
curl -s https://raw.githubusercontent.com/lindell/multi-gitter/master/install.sh | sh
```

### From source
You can also install from source with `go install`, this is not recommended for most cases.
```bash
go install github.com/lindell/multi-gitter@latest
```

## Token

To use multi-gitter, a token that is allowed to list repositories and create pull requests is needed. This token can either be set in the `GITHUB_TOKEN`, `GITLAB_TOKEN`, `GITEA_TOKEN` environment variable, or by using the `--token` flag.

### GitHub

[How to generate a GitHub personal access token (classic)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic). Make sure to give it `repo` permissions.

### GitLab

[How to generate a GitLab personal access token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html). Make sure to give to it the `api` permission.

### Gitea

In Gitea, access tokens can be generated under Settings -> Applications -> Manage Access Tokens

## Config file

All configuration in multi-gitter can be done through command line flags, configuration files or a combination of both. If you want to use a configuration file, simply use the `--config=./path/to/config.yaml` option. Multi-gitter will also read from the file `~/.multi-gitter/config` and take and configuration from there. The priority of configs are first flags, then defined config file and lastly the static config file.

All available run options

```yaml
# The username of the assignees to be added on the pull request.
assignees:
- example

# Email of the committer. If not set, the global git config setting will be used.
author-email:

# Name of the committer. If not set, the global git config setting will be used.
author-name:

# The branch which the changes will be based on.
base-branch:

# Base URL of the target platform, needs to be changed for GitHub enterprise, a self-hosted GitLab instance, Gitea or BitBucket.
base-url:

# The name of the branch where changes are committed.
branch: multi-gitter-branch

# The temporary directory where the repositories will be cloned. If not set, the default os temporary directory will be used.
clone-dir:

# Use a code search to find a set of repositories to target (GitHub only). Repeated results from a given repository will be ignored, forks are NOT included by default (use `fork:true` to include them). See the GitHub documentation for full syntax: https://docs.github.com/en/search-github/searching-on-github/searching-code.
code-search:

# The commit message. Will default to title + body if none is set.
commit-message:

# The maximum number of concurrent runs.
concurrent: 1

# What should happen if the branch already exist.
# Available values:
# skip: Skip making any changes to the existing branch and do not create a new pull request.
# replace: Replace the existing content of the branch by force pushing any new changes, then reuse any existing pull request, or create a new one if none exist.
conflict-strategy: skip

# Create pull request(s) as draft.
draft: false

# Run without pushing changes or creating pull requests.
dry-run: false

# Limit fetching to the specified number of commits. Set to 0 for no limit.
fetch-depth: 1

# Fork the repository instead of creating a new branch on the same owner.
fork: false

# If set, make the fork to the defined value. Default behavior is for the fork to be on the logged in user.
fork-owner:

# The type of git implementation to use.
# Available values:
# go: Uses go-git, a Go native implementation of git. This is compiled with the multi-gitter binary, and no extra dependencies are needed.
# cmd: Calls out to the git command. This requires git to be installed and available with by calling "git".
git-type: go

# The name of a GitLab organization. All repositories in that group will be used.
group:
- example

# Include GitLab subgroups when using the --group flag.
include-subgroups: false

# Insecure controls whether a client verifies the server certificate chain and host name. Used only for Bitbucket server.
insecure: false

# Take manual decision before committing any change. Requires git to be installed.
interactive: false

# Labels to be added to any created pull request.
labels:
- example

# The file where all logs should be printed to. "-" means stdout.
log-file: "-"

# The formatting of the logs. Available values: text, json, json-pretty.
log-format: text

# The level of logging that should be made. Available values: trace, debug, info, error.
log-level: info

# If this value is set, reviewers will be randomized.
max-reviewers: 0

# If this value is set, team reviewers will be randomized
max-team-reviewers: 0

# The name of a GitHub organization. All repositories in that organization will be used.
org:
- example

# The file that the output of the script should be outputted to. "-" means stdout.
output: "-"

# Don't use any terminal formatting when printing the output.
plain-output: false

# The platform that is used. Available values: github, gitlab, gitea, bitbucket_server, bitbucket_cloud. Note: bitbucket_cloud is in Beta
platform: github

# The body of the commit message. Will default to everything but the first line of the commit message if none is set.
pr-body:

# The title of the PR. Will default to the first line of the commit message if none is set.
pr-title:

# The name, including owner of a GitLab project in the format "ownerName/repoName".
project:
- group/project

# Skip pull request and only push the feature branch.
push-only: false

# The name, including owner of a GitHub repository in the format "ownerName/repoName".
repo:
- my-org/js-repo
- other-org/python-repo

# Exclude repositories that match with a given Regular Expression
repo-exclude:

# Include repositories that match with a given Regular Expression
repo-include:

# Use a repository search to find repositories to target (GitHub only). Forks are NOT included by default, use `fork:true` to include them. See the GitHub documentation for full syntax: https://docs.github.com/en/search-github/searching-on-github/searching-for-repositories.
repo-search:

# The username of the reviewers to be added on the pull request.
reviewers:
- example

# Skip repositories which are forks.
skip-forks: false

# Skip pull request and directly push to the branch.
skip-pr: false

# Skip changes on specified repositories, the name is including the owner of repository in the format "ownerName/repoName".
skip-repo:
- example

# Use SSH cloning URL instead of HTTPS + token. This requires that a setup with ssh keys that have access to all repos and that the server is already in known_hosts.
ssh-auth: false

# Github team names of the reviewers, in format: 'org/team'
team-reviewers:
- example

# The personal access token for the targeting platform. Can also be set using the GITHUB_TOKEN/GITLAB_TOKEN/GITEA_TOKEN/BITBUCKET_SERVER_TOKEN/BITBUCKET_CLOUD_APP_PASSWORD environment variable.
token:

# The topic of a GitHub/GitLab/Gitea repository. All repositories having at least one matching topic are targeted.
topic:
- example

# The name of a user. All repositories owned by that user will be used.
user:
- example

# The Bitbucket server username.
username:
```

All available merge options

```yaml
# Base URL of the target platform, needs to be changed for GitHub enterprise, a self-hosted GitLab instance, Gitea or BitBucket.
base-url: