| Metadata | |
|---|---|
| cEP | 24 |
| Version | 1.0 |
| Title | Implement Gitmate automations and plugins for coala |
| Authors | Vamshi Krishna Bommerla mailto:[email protected] |
| Status | Proposed |
| Type | Process |
This cEP describes the improvements to the coala workflow and the necessary automation in GitMate to realize it, as a part of the GSoC project.
GitMate is an automation tool for developers. While it works well, there are a number of missing features which would save the time of coala community.
Many of the plugins in GitMate are general plugins, but coala needs more plugins which support coala development workflow. So, this project adds plugins to auto-review, auto-reject, auto-label PRs, assign, unassign issues, squash commits.
The current assign process in coala is to check team membership of a user, difficulty level of the issue and assign the issue to user if eligible. To implement the current assign process in GitMate, IGitt would need to support teams.
Currently, IGitt doesn't support teams and there are no teams in GitLab. Considering GitLab groups and GitHub teams as teams in IGitt is a possible solution for IGitt implementation. But, it requires extra tools to sync GitHub team and GitLab group memberships, which is a manual process and isn't automated yet.
Also, team membership information is not publicly accessible in GitHub, so any system which needs to implement the current assign system would require organization authentication tokens.
The best possible solution would be using an increasing difficulty level order, so that a user can be assigned to an issue only if the user has solved issues of lower difficulty level before requesting to get assigned to a higher difficulty level issue.
If a user completed the lower difficulty level issues in GitHub and want to
work on a higher difficulty level issue in GitLab, he/she has to repeat the
newcomer process in GitLab. To resolve this issue, GitMate needs to find a way
to link GitHub org and GitLab org, this would be easy when they have the same
name, as in the case of coala. But, resolving this issue is out of scope for
this project.
If a user is worthy enough to work on the higher level difficulty issues directly, then that user needs to be manually assigned by the maintainers until that user completes at least one low difficulty issue. Even with current assign system, manual intervention by maintainers is needed to add a user to developers team.
When a PR is opened or updated, if any of PR's commit message referenced
any issues with keywords Fixes or Closes, there is no
CI failure in PR, if author is eligible to get assigned to mentioned issues,
then auto assign the author of the PR to the mentioned unassigned issues. If
the author of the PR isn't eligible to get assigned to the mentioned issues,
missing eligibility conditions will be specified as a comment, which isn't
configurable.
If someone else is assigned to the mentioned issue, GitMate will comment (configurable) on the PR.
If the author of a PR is not a member of the organization, then he/she can't be assigned to any of the issues, a label (configurable) will be added on the PR so that maintainers can identify these type of PRs and GitMate will comment on the PR informing the author of the PR to get invited to the organization before working on any issue. After the newcomer has accepted the invite, he/she needs to re-push to remove the label added by GitMate.
coala can configure this plugin as:
Comment message when someone else is assigned to mentioned issues:
(use {issues} as the placeholder to get links of all assigned issues)
Sorry, but the issues {issues} are assigned to someone else. Please try working on some other issues.
Label to represent that the author of the PR is not a member of the org:
author/non-member
Normally, contributors should make changes in a different branch from the master branch of the forked repository, and submit a PR. But, often coala receives PRs from the master branch of the forked repository.
coala needs a mechanism such that when a PR is opened or updated, GitMate automatically closes PRs opened on certain branch names (master), adds certain label to the PR so that maintainers can identify these type of PRs and comments on the PR informing the author of the PR label to work on a different branch. Comment message, branch names, the label will be configurable.
coala can configure this plugin as:
Branch names: master
Label: status/rejected
Comment message: This PR is rejected. PR should never be opened in master branch, work on a different branch other than master and open a new PR, follow [tutorial](http://api.coala.io/en/latest/Developers/Newcomers_Guide.html#step- 3-creating-a-fork-and-testing-your-changes) if you repeat this again, you may get banned from coala.
When a reviewer reviews a PR, he/she either approves changes or request changes and leaves it there, but the PR would be still in the review queue. So, coala needs a better mechanism to clear review queue when any maintainer reviews PR or when there is any CI failure.
GitMate will consider only maintainer reviews. To consider developer reviews, GitMate and IGitt would need to add support for teams, but using teams in GitMate is not a part of this project. GitMate may consider using teams in the future.
When a PR is opened, updated or when any maintainer reviews the PR, GitMate will remove pending review label and add labels, as per the following conditions:
- WIP label conditions:
- Maintainer requests changes
- GitMate's coala plugin finds defects
- CI tests fail
- Approved label conditions:
- Maintainer approves changes
coala can configure this plugin as:
WIP Label: process/WIP
Pending Review Label: process/pending review
Approved label: status/approved
Newcomers often get confused when they should use Fixes or Closes in a
commit message. So, when a PR is opened or updated, GitMate should
automatically check every commit for issues which are being Fixed or
Closed, if those issues have a label (configurable) which represents bug,
Fixes should be used, else Closes should be used.
When the commit message contains 'Fixes', but the referenced issue don't have a label (configurable) which represents bug, then a comment (configurable) will be added on the PR. Message to be commented can be configured by coala as:
`Fixes` is used in commit message, but the referenced issue doesn't have a
`type/bug` label, if the issue is updated to include the `type/bug` label, then
ask a maintainer to add the required label, else use `Closes`.
When the commit message contains 'Closes', but the referenced issue has bug label, then a comment (configurable) will be added on the PR. Message to be commented can be configured by coala as:
`Closes` is used, but the referenced issue has a `type/bug` label, if the
issue is updated to remove `type/bug` label, then ask a maintainer to remove
the required label, else use `Fixes`.
In both cases, 'process/pending review' label will be removed and 'process/wip'
label will be added. This will be part of Assign label as per review state
plugin.
When a user comments on an issue requesting for assignment to the issue, GitMate will assign comment author to the issue if he/she is eligible to get assigned, else missing eligibility conditions will be specified as a comment, which isn't configurable.
Assign plugin will support configurations for limiting the number of certain labelled issues a member can work on, block assignment for certain users or certain labelled issues, difficulty level order to be followed while assigning issues to members so that they should work on lower difficulty level issues first.
corobo does many of these things, but it is based just on Gitter messages and is used only by coala, but GitMate is based on GitHub or GitLab, used by many other users and is configurable.
Syntax for assign command: @gitmate-bot assign
coala can configure this plugin as:
Block assignment of issues with labels: status/blocked, initiatives/*
Block assignment of issues to users: gitmate-bot, coala-bot
Maximum number of certain labelled issues a member can be assigned:
difficulty/newcomer: 1
Difficulty Level order:
difficulty/newcomer, difficulty/low, difficulty/medium
When a PR is opened or updated, check for merge conflicts in it, if there are any conflicts, mark the PR with a certain label (configurable) and post a message (configurable) as a comment on the PR.
To know if PR has merge conflicts, mergeable property of PR in GitHub
API
and merge_status property of MR in GitLab
API will be
used.
If mergeable property is False, then PR has merge conflicts, similarly if
merge_status property is cannot_be_merged, then fast-forward merge is not
possible, MR needs to be rebased.
coala can configure this plugin as:
Label: needs rebase
Comment message: This PR can't be merged. To merge this PR, first rebase locally. While rebasing, you may come across mid-rebase conflicts. For information regarding how to resolve mid-rebase conflicts, please check this [tutorial](http://gitforteams.com/resources/rebasing.html)
When a user makes changes and wants to update their commit, they should use "git commit --amend" command, but initially, some users have a habit of using "git commit" command, which results in the creation of new commits. To fix this problem multiple commits need to be squashed into one commit.
Newcomers often have difficulty in squashing commits. So, a plugin to squash multiple commits in a PR into one commit will be implemented. This plugin can squash commits made by this PR only.
Syntax for squash command: @gitmate-bot squash {message}
This command will squash all commits in a PR into a single commit with
commit message as {message}. Use \n in message parameter to include a
newline in commit message.