gitmate plugins

[jayvdb]

coala uses http://gitmate.io to automate our systems.

While it works very well, there are a number of plugins which need extra complexity to better suit coala, and there are new plugin ideas we have all the time, but never get around to building. As these are coala-centric enhancements, they often fall off the gitmate priority list. The extensible framework is there; we need to utilise it better.

[jayvdb]

We have rebase and ff plugins, but a lot of maintainer time can be saved by integrating both of those into an auto-merger.

GitLab has a 'merge when pipelines pass' feature, which GitHub doesnt have.
It would be possible to build GitHub support into the IGitt layer, and needs to be combined with a mechanism for checking it succeeded or failed.

However that is still only operating on a single MR. Ideally maintainers can approve a few MRs/PRs, and gitmate looks after the details of getting them rebased & merged if there are no conflicts.

[jayvdb]

Pull Requests from master should be automatically rejected, with instructions on how to fix their branch, fix their master, and resubmit a PR.

(This is a nice easy one, as IGitt already has the metadata needed, and could be done during community bonding, or first coding phase)

[jayvdb]

coala/coala#5155 - Fixes vs Closes automated checking

IGitt has the relevant information : see https://gitlab.com/gitmate/open-source/IGitt/merge_requests/98

[jayvdb]

Note that #489 is a separate project covering enhancements to GitCommitBear especially.

[jayvdb]

Another plugin requested is automatically marking WIP if gitmate's coala plugin finds defects.

[jayvdb]

A squash command would be useful, to automagically fix a PR with lots of messy commits, so we can merge it - helpful to newcomers only , instead of them creating a new PR.

Actually it would be interesting to see how rebase handles a GitHub rebase from master...

Maybe call it something like 'unbork' , so there is a bit of a negative connotation to it, so it isnt used instead of following normal development best practises.

However, there was a suggestion that we move to a GitHub flow , where incremental improvements are added as extra commits until the PR is ready to land, to easy code review, in which case a squash at the end would prepare the PR for landing.

[rohanrk]

I'm be interested in this. You said that the documentation is stored in the webapp? How do newcomers access those docs?

Also automatically mark PRs that fail CI as WIP would be a good plugin.

[jayvdb]

You'll need to ask the gitmate devs, almost all of which are also coala developers. Their source is at https://gitlab.com/gitmate/open-source

[Makman2]

I would like to see advanced configuration management, what I currently have in mind is to manage a set of configurations that can be applied quickly to multiple projects at once or are automatically synced if a repo uses that configuration.
Changing a single setting inside a repo in an organization and making it reflect in all other repos is a pain for 5+ repos.

EDIT:
I would like to see -> I think it would be a useful feature for this gsoc project

[jayvdb]

@Makman2 , @nkprince007 , see #487 for configuration of gitmate from YAML inside a repo (and we would do the syncing between repos in another tool; likely moban)

[jayvdb]

The project page should have been updated during bonding, but too late for that I guess. See cEP for final project concepts.