{"id":48,"date":"2019-11-02T23:28:44","date_gmt":"2019-11-02T23:28:44","guid":{"rendered":"https:\/\/blog.simulakrum.diskstation.eu\/?p=48"},"modified":"2019-11-02T23:28:46","modified_gmt":"2019-11-02T23:28:46","slug":"jenkins-and-gerrit-trigger-for-the-win","status":"publish","type":"post","link":"https:\/\/blog.simulakrum.vpndns.org\/?p=48","title":{"rendered":"Jenkins and Gerrit Trigger for the win"},"content":{"rendered":"\n<p>I had quite a few problems setting the workflow as follows:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>I&#8217;d make a change in <em>ansible<\/em> files, and push them to a <em>git<\/em> behind <em>Gerrit<\/em><\/li><li><em>Gerrit<\/em> would trigger <em>Jenkins<\/em> with the new commit, and <em>Jenkins<\/em> would apply the <em>linter<\/em> on the committed files. If all is good, the files are send upstream to <em>Rundeck<\/em> that than picks the nodes from the inventory and plays the books, and <em>Jenkins<\/em> gives <strong>+1 Verify<\/strong> and <strong>+2 Code Review<\/strong> (yes, I want it to do all the job \ud83d\ude42 and <em>Gerrit<\/em> merges the commit via a <em>rebase always<\/em> strategy; however, when <em>linter<\/em> marks the build as failed, it returns the <strong>-1 Verify<\/strong> and a &#8220;<strong>fail<\/strong>&#8221; for <strong>Code Review<\/strong> to <em>Gerrit<\/em>, and kicks no job on <em>Rundeck<\/em> until a build is fixed. Here started the problems&#8230;<\/li><\/ul>\n\n\n\n<p><em>Jenkins<\/em>&#8216; <em>Gerrit<\/em> <em>trigger<\/em> page describes well what should be done with access for <em>refs<\/em> in <em>Gerrit<\/em>, but here&#8217;s the extra that makes all the difference:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>in <em>Gerrit Reporting Values<\/em> in the trigger set-up, the following should be add for the fields:<br>for <em>Verify<\/em>:<br><strong>&#8211; Started: 0<br>&#8211; Successful: 1<br>&#8211; Failed: -1<br>&#8211; Unstable: 0<br>&#8211; Not Built: -1<\/strong><br>for <em>Code Review<\/em>:<br><strong>&#8211; Started: 0<br>&#8211; Successful: 1<br>&#8211; Failed: -1<br>&#8211; Unstable: 0<br>&#8211; Not Built: -1 <\/strong><br>for <em>Gerrit Verified Commands<\/em>, under <em>Successful<\/em> a <strong><em>&#8211;submit<\/em><\/strong> should be added in the line.<\/li><li><strong>Enable Manual Trigger<\/strong>, and do not use <em>REST API<\/em> (using <em>ssh<\/em> here already)<\/li><li>Under the very job settings, in <em>Source Code Management<\/em>, for <em>Refspec<\/em> <a href=\"https:\/\/config9.com\/apps\/jenkins\/jenkins-gerrit-trigger-not-fetching-my-change-when-building\/\">the following<\/a> is required <strong>$GERRIT_REFSPEC:$GERRIT_REFSPEC <\/strong>and under <em>Branches<\/em> to build <strong>$GERRIT_REFSPEC<\/strong> because this will assure that <em>Jenkins<\/em> picks the amended commit, and not one commit after the last known commit to be good; if not set like this, <em>Jenkins<\/em> will keep pulling the main suspect for the broken build and keep trying to use it to produce a fixed build. Lovely, eh. <\/li><li>In <em>Gerrit Trigger<\/em> in the very job settings, under <em>Advanced >> Code Review >> Successful <\/em>a <strong>2<\/strong> is desired, because we want <em>Jenkins<\/em> and <em>Gerrit<\/em> to do all the job of the code review for us. Trigger this on <strong>Patchset Created<\/strong> and <strong>Draft Published<\/strong>, excluding all cases of changes for <em>patchset<\/em> creation. The <em>pattern<\/em> is of a <em>plain type<\/em> and it is your repo, and the <em>branches<\/em> are of a <em>type path<\/em> with <strong>**<\/strong> as the option.<\/li><li>Delete the environment before the build starts.<\/li><li>Under Build the whole show takes place, it is up to you &#8211; what do you want to happen there.<\/li><li>Post-build actions now trigger <em>Rundeck<\/em> only on success. <\/li><\/ul>\n\n\n\n<p>If the rest is set well, time is for a test &#8211; ruin a build purposefully in a file, commit and push to <strong><em>refs\/heads\/:refs\/for\/ <\/em><\/strong>and sit and watch how <em>Jenkins<\/em> tells <em>Gerrit<\/em> to mark the commit that ruined the build as failed and to keep it in Limbo. Then do an amend with a fix, and <em>Jenkins<\/em> will re-build the stuff, tell <em>Gerrit<\/em> it is all ok now, and simultaneously send a signal to <em>Rundeck<\/em>. <em>Gerrit<\/em> will auto-merge this time good code to master, and the rest of the devs can pick up from there.<\/p>\n\n\n\n<p>P.S. If people keep committing a new <em>patchset<\/em> instead of amending it for <em>Gerrit<\/em>, start yelling after the second time it happens, it might help do the manual monster merges that will follow&#8230; <\/p>\n\n\n\n<p><\/p>\n\n\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>I had quite a few problems setting the workflow as follows: I&#8217;d make a change in ansible files, and push them to a git behind Gerrit Gerrit would trigger Jenkins with the new commit, and Jenkins would apply the linter on the committed files. If all is good, the files are send upstream to Rundeck that than picks the nodes &hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-48","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blog.simulakrum.vpndns.org\/index.php?rest_route=\/wp\/v2\/posts\/48","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.simulakrum.vpndns.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.simulakrum.vpndns.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.simulakrum.vpndns.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.simulakrum.vpndns.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=48"}],"version-history":[{"count":1,"href":"https:\/\/blog.simulakrum.vpndns.org\/index.php?rest_route=\/wp\/v2\/posts\/48\/revisions"}],"predecessor-version":[{"id":49,"href":"https:\/\/blog.simulakrum.vpndns.org\/index.php?rest_route=\/wp\/v2\/posts\/48\/revisions\/49"}],"wp:attachment":[{"href":"https:\/\/blog.simulakrum.vpndns.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=48"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.simulakrum.vpndns.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=48"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.simulakrum.vpndns.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=48"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}