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 _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
