[Paraview-developers] New merge request robot behaviors
Ben Boeckel
ben.boeckel at kitware.com
Thu Feb 2 14:52:14 EST 2017
Hi all,
Recently, Brad and I have been working on revamping the kwrobot from its
initial implementation. It now has unit tests and its source is
available (see below).
In addition, buildbot will be changing its default behavior from "test
this and all future updates" to "test just this update". Basically,
`--oneshot` is now assumed and the flag itself is ignored. This was
announced a while ago without any disagreements, but is finally going
into effect.
Merge requests will need the new robot to check them. It will do this if
the merge request changes or on a manual `Do: check`.
# What does this mean for me?
Ideally, not much. The only behavior changes (should) be:
- If you select "Delete source branch" when creating a merge request,
the robot will now delete it for you when it is merged.
- No more "Failed to merge the tree because ???" errors.
- Failures in git commits are now formatted better with Markdown
rather than dumped out as a pre-formatted block.
- The kwrobot user will mark comments with `Do:` commands with a robot
emoji (🤖) to indicate that it handled the command. In the case of
success, it will *not* make its own comment (buildbot will still
make its comment for `Do: test` commands), but instead just do the
action and put a status check on the latest commit on the merge
request.
- No more race conditions; saying `Do: test` before kwrobot gives its
pass/fail check will not be ignored.
- Lighter buildbot loads by only building explicitly requested merge
requests.
# Why this new code?
The original robot was written with VTK and ParaView's workflows in
mind, however the goal of porting the CMake workflow over exposed severe
design limitations in it. With its lack of a test suite, it made making
those changes potentially dangerous. It also lacked logging and
robustness against errors, as evidenced by the "Failed to merge"
problems of late.
# Where can I report issues?
In general, on the [ghostflow-director issues][] page. We may move
your issue to a different repository depending on where it belongs.
# Where is the code?
All of the repositories are available under the [utils group][]. A
general breakdown for the repositories relevant to the VTK, VTK-m,
ParaView, and CMB projects:
- rust-git-workarea: contains core building blocks for operations used
elsewhere
- rust-git-checks: checks performed for on git commits
- rust-gitlab: communication with Gitlab
- rust-ghostflow: implementation of the `Do:` commands (check, test,
merge, ExternalData sync); mechanisms of the workflow live here
- webhook-listen: listens for webhook events from Gitlab
- ghostflow-director: the robot itself; handles jobs from Gitlab and
performs the relevant actions; policies of the workflow live
here
Thanks,
--Ben
[ghostflow-director issues]: https://gitlab.kitware.com/utils/ghostflow-director/issues
[utils group]: https://gitlab.kitware.com/groups/utils
More information about the Paraview-developers
mailing list