[vtk-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 vtk-developers mailing list