[vtk-developers] gitlab-push woes

[Ben Boeckel]

On Sat, Mar 21, 2015 at 11:03:41 -0400, Ken Martin wrote:
> 1) Make @buildbot and Do: consistent. It seems odd to do "Do: check" or
> "Do: merge" and then "@buildbot test".  I would expect "Do: test"

I agree, but currently these are managed by completely different tools.
Currently, they have no knowledge of each other and keeping kwrobot
configuration kept up-to-date in tandem with buildbot changes is not
something I want to maintain long-term.

The best solution would be to have kwrobot tell buildbot to do things
rather than having buildbot do its own scraping[1], but this is not even
started (and I don't have a timeline for it right now since I have other
projects that need attention now that the infrastructure is in a
workable state). Once kwrobot is doing the buildbot orchestration, I
would support adding a "Do: build" command since it would go through the
same code as the existing "Do:" commands.

> 2) Recognition is better than remembering. It is easier for infrequent
> developers to **recognize** what they want to do rather than
> **remembering** what to do. A good example of this is if you add "Do:
> oops" to a merge request it will respond with a list of valid options so

Kwrobot will respond to unknown commands with what it is configured to
understand (for that project; some are set up to just have checks done
and not merging). Currently, buildbot is silent except for the "your
builds have been scheduled", but similar error messages can be added
until the "Do: build" logic is implemented.

> that you can **recognize** what you really wanted, as opposed to just
> responding with an error and forcing the user to again try to **remember**
> the correct option.  In that vein it might be nice to have the frequently
> used commands shown.  Ideally the GUI has them as options and the user
> just picks (recognition), but that means messing with the GUI. A not quite
> as good alternative would be to maybe have a small part of the GUI on the
> merge request page show the basic commands
> 
> Do: ***
> @buildbot ***
> Add reviewer with @...
> 
> Or maybe have the "Do: check" output include that help  sort of a
> 
> "Hey passed basic content checks, the next steps are often...  Do: ****,
> @buildbot **** etc"

Changing the UI to have the instructions verbatim is not trivial
maintenance-wise (it's not something we can upstream and we would have
to patch on every upgrade). Instead, having the MR submission and view
have links to guidelines and workflows would be upstreamable, but these
should be placed in the repository so we can link to them and don't need
to patch our GitLab instance for workflow changes. I can add this to the
TODO list, but since this likely would require a database change (for
the file to link to), is something that may take longer to figure out
how to do properly.

In the meantime, I can have kwrobot add a link to the "help"
documentation on a per-project basis (again, I don't want it to be
static so it isn't spammy and I don't want to have to make kwrobot
updates for workflow documentation changes).

--Ben

[1]This would also keep the logic in one place for not scheduling builds
for MRs with Rejected-by comments, requiring at least an Acked-by on
external contributions before they are scheduled, etc.