Last modified: 2014-11-19 22:41:56 UTC
The job will vote -1. But only in gate-and-submit, when working on it the tests should pass (or have this one be non-voting).
I would prefer we do not rely on the commit summary having WIP or DRAFT in it, though we might warn about it. OpenStack has a patch for Gerrit (might have been upstreamed), that let you flag a change has being a work in progress (see original feature request https://bugs.launchpad.net/openstack-ci/+bug/902953 ). From Gerrit 2.5 release-notes, the drafts do not send patchset-created events so they should not trigger any job. When they are published we have a new `draft-published` event which is essentially the same as patchset-created. I guess voting CodeReview +2 on a draft will thus send no event at all and the change will obviously never enter any pipeline.
Looking at the dashboard of VisualEditor extension that makes a lot of sense :) https://gerrit.wikimedia.org/r/#/projects/mediawiki/extensions/VisualEditor,dashboards/default $ git-review -l|egrep '(WIP|MERGE)' 70560 master [WIP] Language Inspector Prototype 71641 master [DON'T MERGE] Remove 'mw-editsection-bracket' hack 71285 master [WIP] Do not allow to resize thumb image to be bigger than original file 70346 master [DON'T MERGE] Rich Copy and Paste from External Source 69796 master [DON'T MERGE] Rich paste from external sources 71661 master [WIP] ve.dm.Transaction: Implement newFromDocumentInsertion, take 2 70981 master [WIP] Math Node UI 68615 master [WIP] Source code editing 70171 master [WIP] Math Node Matcher 69281 master [WIP] Link surface fix for RTL $
*** Bug 53405 has been marked as a duplicate of this bug. ***
Revisiting after a while: Zuul does not have support to prevent merge based on a the content of the commit message. A possibility is to use Code-Review: -2 which will effectively prevent Gerrit from submitting the patch. Another way would be to add a new label in Gerrit that would be used to flag a change has being in progress which would trigger the gate-and-submit when voted +1. Something like: Approval: +1 Approved 0 Pending review -1 Work in progress Timo thoughts? Or should we just abandon this idea?
(In reply to Antoine "hashar" Musso (WMF) from comment #4) > Revisiting after a while: Zuul does not have support to prevent merge based > on a the content of the commit message. Really? The Jenkins jobs have a full git checkout, so presumably you could write a jenkins job for gate-and-submit that runs: git log --oneline | head -1 | fgrep -q WIP The actual test would be a little more complicated, since you'd want to be sure you were looking at the right side of a merge commit, but either HEAD^1 or HEAD^2 would name the actual patch you're committing in that case.
