GitLab MR formatter #351
GitLab MR formatter #351
Conversation
Co-Authored-By: Willian van der Velde <[email protected]>
Since, as the name implies, the merge request formatter comments on merge requests we can require that the GitLab CI jobs run in a [merge request pipeline][1] which automatically sets [``CI_MERGE_REQUEST_IID``][2]. This avoids having to guess the merge request id based on the branch/commit which could lead to false positives. [1]: https://docs.gitlab.com/ee/ci/merge_request_pipelines/ [2]: https://docs.gitlab.com/ce/ci/variables/predefined_variables.html
|
I don't like this choice as it requires gitlab premium. It's nice that the version in my pull request #349 functions out of the box with gitlab core/starter |
|
It doesn't require any premium feature, we are running this branch on the pure open source CE of GitLab. I have not seen your PR before, if I did I wouldn't have opened this one :/ I removed the branch guessing because I thought a smaller change would be easier for the maintainers, but I am obviously also happy with our changes (even though adding |
|
I could have sworn pipleines for merge requests was a preimum feature, guess I was wrong... |
|
Hey all. Any news about the state of this PR? |
|
I can close #349, then I would assume this is ready for merge |
|
Just tested this and it works pretty well. Can the maintainers merge this and release a new gem version? |
|
Any updates on when this might get merged? |
|
Sorry for the delay all. I'm the primary maintainer these days it seems and I'm currently recovering from a pretty serious back injury that is limiting my time. |
* Gitlab formatter * Update README.md Co-Authored-By: Willian van der Velde <[email protected]> * Fix the specs * Require `gitlab_mr` formatter to be run in a merge request pipeline Since, as the name implies, the merge request formatter comments on merge requests we can require that the GitLab CI jobs run in a [merge request pipeline][1] which automatically sets [``CI_MERGE_REQUEST_IID``][2]. This avoids having to guess the merge request id based on the branch/commit which could lead to false positives. [1]: https://docs.gitlab.com/ee/ci/merge_request_pipelines/ [2]: https://docs.gitlab.com/ce/ci/variables/predefined_variables.html * Update README
This is based on the work of @Strnadj in #308.
Since he started GitLab added pipelines for merge requests which removes the need to guess the merge request for the current branch/commit. In addition to that it also re-runs jobs when the merge request target branch is changed.