groq/marge-bot

groq/marge-bot

Language: Python

License: BSD-3-Clause

Stars: 1

Forks: 3

Open issues: 0

Created: 2019-11-06T17:43:28Z

Pushed: 2022-07-07T23:56:33Z

Default branch: master

Fork: yes

Parent repository: bsima/marge-bot

Archived: yes

README: 

Marge-bot

Marge-bot is a merge-bot for GitLab that, beside other goodies, implements the Not Rocket Science Rule Of Software Engineering:

> automatically maintain a repository of code that always passes all the tests.

— Graydon Hoare, main author of Rust

This simple rule of thumb is still nowadays surprisingly difficult to implement with the state-of-the-art tools, and more so in a way that scales with team size (also see our blog post).

Take, for instance, GitHub's well-known pull-request workflow. Here, CI needs to pass on the branch before the pull request can be accepted but after that, the branch is immediately merged (or rebased) into master. By the time this happens, enough changes may have occurred to induce test breakage, but this is only to be found out when the commits have already landed.

GitLab (in their enterprise edition), offers an important improvement here with their semi-linear history and fast-forward merge request methods: in both cases a merge request can only be accepted if the resulting master branch will be effectively the same as the merge request branch on which CI has passed. If master has changed since the tests were last ran, it is the *user's responsibility* to rebase the changes and retry. But this just doesn't scale: if you have, a mono-repo, a large team working on short-lived branches, a CI pipeline that takes 5-10 minutes to complete... then the number of times one need's to rebase-and-try-to-accept starts to become unbearable.

Marge-bot offers the simplest of workflows: when a merge-request is ready, just assign it to its user, and let her do all the rebase-wait-retry for you. If anything goes wrong (merge conflicts, tests that fail, etc.) she'll leave a message on the merge-request, so you'll get notified. Marge-bot can handle an adversarial environment where some developers prefer to merge their own changes, so the barrier for adoption is really low.

Since she is at it, she can optionally provide some other goodies like tagging of commits (e.g. Reviewed-by: ...) or preventing merges during certain hours.

Configuring

Args that start with '--' (eg. --auth-token) can also be set in a config file (specified via --config-file). The config file uses YAML syntax and must represent a YAML 'mapping' (for details, see http://learn.getgrav.org/advanced/yaml). If an arg is specified in more than one place, then commandline values override environment variables which override config file values which override defaults.

optional arguments:
-h, --help show this help message and exit
--config-file CONFIG_FILE
config file path [env var: MARGE_CONFIG_FILE] (default: None)
--auth-token TOKEN Your GitLab token.
DISABLED because passing credentials on the command line is insecure:
You can still set it via ENV variable or config file, or use "--auth-token-file" flag.
[env var: MARGE_AUTH_TOKEN] (default: None)
--auth-token-file FILE
Path to your GitLab token file.
[env var: MARGE_AUTH_TOKEN_FILE] (default: None)
--gitlab-url URL Your GitLab instance, e.g. "https://gitlab.example.com".
[env var: MARGE_GITLAB_URL] (default: None)
--ssh-key KEY The private ssh key for marge so it can clone/push.
DISABLED because passing credentials on the command line is insecure:
You can still set it via ENV variable or config file, or use "--ssh-key-file" flag.
[env var: MARGE_SSH_KEY] (default: None)
--ssh-key-file FILE Path to the private ssh key for marge so it can clone/push.
[env var: MARGE_SSH_KEY_FILE] (default: None)
--embargo INTERVAL[,..]
Time(s) during which no merging is to take place, e.g. "Friday 1pm - Monday 9am".
[env var: MARGE_EMBARGO] (default: None)
--use-merge-strategy Use git merge instead of git rebase to update the *source* branch (EXPERIMENTAL)
If you need to use a strict no-rebase workflow (in most cases
you don't want this, even if you configured gitlab to use merge requests
to use merge commits on the *target* branch (the default).)
[env var: MARGE_USE_MERGE_STRATEGY] (default: False)
--add-tested Add "Tested: marge-bot " for the final commit on branch after it passed CI.
[env var: MARGE_ADD_TESTED] (default: False)
--batch Enable processing MRs in batches
[env var: MARGE_BATCH] (default: False)
--add-part-of Add "Part-of: " to each commit in MR.
[env var: MARGE_ADD_PART_OF] (default: False)
--add-reviewers Add "Reviewed-by: $approver" for each approver of MR to each commit in MR.
[env var: MARGE_ADD_REVIEWERS] (default: False)
--impersonate-approvers
Marge-bot pushes effectively don't change approval status.
[env var: MARGE_IMPERSONATE_APPROVERS] (default: False)
--approval-reset-timeout APPROVAL_RESET_TIMEOUT
How long to wait for approvals to reset after pushing.
Only useful with the "new commits remove all approvals" option in a project's settings.
This is to handle the potential race condition where approvals don't reset in GitLab
after a force push due to slow processing of the event.
[env var: MARGE_APPROVAL_RESET_TIMEOUT] (default: 0s)
--project-regexp PROJECT_REGEXP
Only process projects that match; e.g. 'some_group/.*' or '(?!exclude/me)'.
[env var: MARGE_PROJECT_REGEXP] (default: .*)
--ci-timeout CI_TIMEOUT
How long to wait for CI to pass.
[env var: MARGE_CI_TIMEOUT] (default: 15min)
--max-ci-time-in-minutes MAX_CI_TIME_IN_MINUTES
Deprecated; use --ci-timeout.
[env var: MARGE_MAX_CI_TIME_IN_MINUTES] (default: None)
--git-timeout GIT_TIMEOUT
How long a single git operation can take.
[env var: MARGE_GIT_TIMEOUT] (default: 120s)
--git-reference-repo GIT_REFERENCE_REPO
A reference repo to be used when git cloning.
[env var: MARGE_GIT_REFERENCE_REPO] (default: None)
--branch-regexp BRANCH_REGEXP
Only process MRs whose target branches match the given regular expression.
[env var: MARGE_BRANCH_REGEXP] (default: .*)
--debug Debug logging (includes all HTTP...