Really like the "Build +1" flag option: it would be an even more explicit tracking of "ready to be built" status, to avoid the painful and expensive waste of build resources.
Luca. On 8 May 2014, at 09:19, Sandell, Robert <[email protected]> wrote: > Perhaps Gerrit is sending patchset-created events to users that are invited > to the draft change, and since one patch set is revealed to the Jenkins user > and Jenkins then has posted a comment on the patch set it's considered to be > able to view the draft. > > Unless you have other reasons for using the draft method than to hide the > changes from Jenkins; you could change your jobs to trigger when the patch > set gets a "code review +2" or any custom label like "build +1". It would > have the same effect in that it would not trigger until a code review is done. > > > Robert Sandell > Sony Mobile Communications > Tel: +46 10 80 12721 > sonymobile.com > > From: [email protected] [mailto:[email protected]] > On Behalf Of Jens Löök > Sent: den 7 maj 2014 15:31 > To: [email protected] > Cc: Jens Löök > Subject: Re: Gerrit issue with drafts > > I don't think so, as far as I can tell it is not possible to figure out that > a draft on top of a public change-set actually is a draft from the message > that is sent. But in the Gerrit gui the new change-set is marked as a draft. > So the message that is picked up by the Gerrit trigger in Jenkins does not > get the same information as the gui. > > /Jens > > Den onsdagen den 7:e maj 2014 kl. 14:01:30 UTC+2 skrev lucamilanesio: > Seems like a Gerrit-trigger-plugin issue rather than Gerrit. > Have you shared it on the Jenkins mailing list ? > > Sent from my iPhone > > On 7 May 2014, at 12:39, Jens Löök <[email protected]> wrote: > > Hi > I sent this issue on our internal mailing list at Ericsson and it was > suggested to post it here as well it would be interesting to hear your > thoughts on this matter. > I did a quick search but nothing to obvious came up so I hope I'm not posting > something that comes up a lot here. > > We have defined a work flow where we use drafts in Gerrit to lighten the load > on our build machinery a bit. The scenario is that you can get the review out > of the way before you actually trigger the build and test jobs. > > We are using "git-review" addon to submit changes to Gerrit and we have > changed the default behavior of git-review to always create drafts, you can > still submit with -P to get a public change (it is configurable for each repo > if the default action should be publish or draft). > > Now to our issue, if you have a change that contains one or several draft > patch-sets and then you make the change public either by pushing the Publish > button in the gui or by creating a new patch-set that is public our review > job will be triggered. And if you need to create additional patch-sets to fix > any problem in the review job all new patch-sets will trigger the review job > no matter if you send them to refs/drafts och refs/publish. If you create a > new draft change-set on top of a public change-set the review job will be > kicked off because the "patchset-created" message from Gerrit contains > "status":"NEW" but in the GUI the new patch-set will have status DRAFT and > you will need to do publish before you can do submit and this will trigger > two review-jobs for the same patch-set. > > To me it seems like Gerrit is a bit inconsistent here and the behavior should > be changed so that > - a new draft patch-set on top of a public patch-set does not trigger a > build, the message from Gerrit should still contain"status":"DRAFT" . > or > - a new draft patch-set on top of a public patch-set becomes a public > change by default and you do not need to publish it before it can be > submitted. > -- > -- > To unsubscribe, email [email protected] > More info at http://groups.google.com/group/repo-discuss?hl=en > > --- > You received this message because you are subscribed to the Google Groups > "Repo and Gerrit Discussion" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
