Approximating a missing platform with gerrit

On Mon, Thu Jul 16 00:26:35 PDT 2015, Stephan Bergmann wrote:

> But when you try to (mis-)use it to modify a change 
> request [...] the situation is not that ideal.

As you noticed, these are two entirely different use cases:

1. automatic "ready-to-go" gerrit change verification on all platforms
with standard configure settings and make command invocation

2. platform specific verification with custom configuration options and
make command invocation

Whatever we could do for use case 2. (later more on this) we should
first polish and understand the limitation of 1. Sorry for abusing your
thread for that.

I learned yesterday, that our Jenkins/Gerrit Trigger Plugin/Gerrit
integration has one problem: 

"Sets build current patches only mode." option, that does this:

"If this is enabled, all currently running or scheduled builds for
previous patchsets will be canceled before a new build is scheduled for
the new patchset."

wasn't activated in out setup. The reason for that is that there are
intermittent problem with canceling build on windows platform.

However, until we can find out how to overcome these problems and
activate the option we must understand the consequences this option not
being set:

a) Don't upload to Gerrit non-ready vanilla changes
b) Don't upload to Gerrit non-ready vanilla patch sets

Because pushing to gerrit immediately triggers 3 verification jobs.
Uploading new patch set re-triggers new 3 verification jobs, *without*
canceling already running (and thus obsolete) jobs for now outdated
patch sets.

Simple example calculation: pushing 5 patch set within 20 min. as I did
yesterday: [1], triggers 5 x 3 = 15 jobs. Given that all these patches
weren't ready yet, and all I wanted is to share my discovering and
thoughts with reviewers of this change, this was incredible waste of
resources. To make it clear, my intention was *not* to spawn 15 Jenkins
jobs for non ready change.

That rises the question how should a contributor to share her thoughts
(and code) with core developers, for non-ready (aka Work In Progress or
just WIP) changes, without spamming developer mailing list with
attachments (that get removed) or not to mention sending them private
mails (that would end up in spam folder and get ignored)? IOW How to
"hide" WIP changes from the our Jenkins/Gerrit verification tool chain,
and avoid wasting of real world resources, and keep our planet green?

One feature that Jenkins/Gerrit integration offers you is use DRAFT
changes and DRAFT patch sets (those are not the same).

The easiest way to grasp this non trivial concept, is imagine two
database tables in Gerrit with two DRAFT columns:

CHANGES
=======
DRAFT: boolean
[...]

PATCH_SETS
==========
DRAFT: boolean
[...]

It should be clear from this, that there can be a DRAFT patch for no
DRAFT change. When a change is in status DRAFT, then all patch sets are
DRAFTs as well.

There can be many different DRAFT workflows:

I. change is WIP from the beginning (non ready):

  $ git push HEAD:refs/drafts/master

or alternatively magic branch option can be used

  $ git push HEAD:refs/for/master%draft

This way created change has status DRAFT, and is not "seen" by Jenkins
and is not get verified.

II. draft patch set should be uploaded for non DRAFT change.

Command is identical as above. New patch set has status draft.

Note, that DRAFT changes an patch sets must be published (and can be
even deleted) to be promoted to regular changes.

Also note, that pushing follow-up patch sets *without* marking them as
DRAFT would effectively publish them. So just keep pushing with DRAFT
marker as explain above to make DRAFT status sticky.

Now back to your original question, after explanation of DRAFT workflow.

What we could do to cover the second use cases you mentioned is to
combine Jenkins/Trigger plugin automatic verification for regular
changes/patch sets with manual triggering of DRAFT patch set per
platform with Gerrit Buildbot plugin.

Gerrit buildbot plugin could be adapted to only consider DRAFT
changes/patch sets and offer a "Schedule" button on change screen for
each platform (another option is to use one button, and offer check
boxes on popup window per platform that should be built). Clicking on it
would open a popup dialog, where custom configure and make file options
could be provided. The same tinderboxes could be run in mixed Jenkins
Trigger Plugin/Gerrit Buildbot plugin mode and verify regular patch sets
in Jenkins/Trigger plugin mode and DRAFT patch set in Gerrit buildbot
plugin mode.

To summarize your workflow would be:

* upload regular (optionally as DRAFT, abd even avoid building you
intermediate change on all three platforms) change that is verified by
regular Jenkins/Trigge rplugi integration
* upload 42 new DRAFT patch sets, and trigger verification with Buildbot
plugin schedule button manually for interesting platform. This would
schedule dedicated build on specific platform you selected with custom
settings (of course TB must know and support them).
* once you are satisfied with the results of last draft patch set, you
publish it and patch set number 43 is get verified by regular
Jenkins/Trigger plugin integration on all platforms.  

[1] https://gerrit.libreoffice.org/17056