Auto assign randomly a user to a merge request
To work properly, gitlab-auto-assignee need some environements variables to be setup. You can find the list below:
Name | Req. | Ini. Val. | Description |
---|---|---|---|
GAA_API_TOKEN | ✔️ | Token used by the hook to access the api, it needs api rights. Also, the user associated to the token need to have correct access to repository and groups which it will interact with. | |
GAA_USER_ID | ✔️ | User id of the user associated to GAA_API_TOKEN. We need it to avoid assigning the user to a merge-request. | |
GAA_SECRET_TOKEN | ✔️ | Secret token used to authenticate requests. | |
GAA_RULES_URL | ✔️ | Url of your configuration file. A Get request is done on that url for each merge-request. To learn more about the configuration file check section 2. | |
GAA_API_URL | https://gitlab.com | Gitlab url. | |
GAA_PORT | 3000 | Port used by the hook. |
First of all, you have to configure a webhook on repositories on which you want gitlab-auto-assignee to work on.
The webhook url is $yourUrl/mr
, where $yourUrl is the url on which you will deploy the app.
Check Merge requests events
as trigger of the webhook. All other events are ignored.
You can find more informations about gitlab webhook here
To build and install the hook from sources, you need to checkout the repository and build the project like a classique javascript module.
Be sure to set all required environements variables in your bashrc or inline when using yarn start
.
git clone [email protected]:babeya/gitlab-auto-assignee.git
yarn install
yarn start
There is a ready to use docker image available at ghcr.io/babeya/gitlab-auto-assign:latest.
docker run -d -p 3000:3000 --env [your environements] ghcr.io/babeya/gitlab-auto-assign:latest
The config files is used to define which members and how many will be assigned to new merge requests.
You can use this file as a base for your own.
If you do, you have to add projectIds and the groupId coresponding to your needs.
You can host the file where you want (a git repository works great), but you have to ensure access for the hook.
Below a more complete example :
{
"projects": [
// You can setup multiple rules on different repository with different group, just ensure the bot has access to all groups and project
{
"projectIds": [1], // Project ids on which subsequent rules while applies
"groupId": 1, // Id of the group acting as a pool of user
"rules": [
{
"branch": ["master"], // Target branch
"minLevel": 40, // Minimum access level required to be assigned
"nbReviewers": 2 // Number of user to assign
},
{
"branch": ["all"], // all is an alias matching all target branch
"minLevel": 30,
"nbReviewers": 2
}
]
},
{
"projectIds": [2, 4, 5],
"groupId": 3,
"rules": [
{ "branch": ["dev"], "minLevel": 30, "nbReviewers": 1 },
{ "branch": ["master"], "minLevel": 40, "nbReviewers": 2 }
]
}
]
}
To learn more about gitlab access levels you can check this page.
Below a simple cheat sheet summing it up:
- 50 -> Owner
- 40 -> Maintainer
- 30 -> Developer
- 20 -> Reporter
- 10 -> Guest