<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 9:03 PM, Vojtech Szocs <span dir="ltr">&lt;<a href="mailto:vszocs@redhat.com" target="_blank">vszocs@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hello folks,<br>
<br>
this was discussed some time ago, but we&#39;re gonna make oVirt Dashboard<br>
build-artifacts.sh tag-sensitive (if the commit is tagged, it indicates<br>
release build, so we&#39;ll drop the {date}git{commit} part of RPM release).<br>
<br>
The relevant Dashboard patch is here: <a href="https://gerrit.ovirt.org/#/c/60988/" rel="noreferrer" target="_blank">https://gerrit.ovirt.org/#/c/60988/</a><br>
<br>
Question: is it possible to execute build-artifacts.sh after a tag gets<br>
pushed into Gerrit repo? (or at least make it opt-in via the Jenkins job<br>
config somehow?)<br>
<br>
Or should we just use Jenkins / Gerrit manual trigger to re-build from<br>
given commit once it&#39;s tagged in Gerrit repo?<br></blockquote><div><br></div><div>I think the best way will be to add logic to build artifacts code (post merge)</div><div>Same as you&#39;re doing in the patch, so once you merge a tag, its same as you would have a merge a code change, </div><div>build-artifacts.sh will trigger a new build and create the rpm based on the logic you will tell him.</div><div><br></div><div>Another option will be to add new file called build-official-artifacts.sh which will only build from tags</div><div>and then we can collect it to stable repos instead of snapshot repos, I will need to see what</div><div>does it mean to add another &#39;build artifacts&#39; job to standard CI, but I don&#39;t believe it should be complicated, probably another stage like we have check-patch and check-merged. </div><div><br>I actually wanted to suggest this option as a first attempt to automate the official builds and stop using the manual way of tar.gz,</div><div>One more thing you might want to do in the official build artifacts is to sign the RPM.</div><div><br></div><div>As for manual trigger, you can do it today with build-artifacts, just give it the tag refspec:</div><div><a href="http://jenkins.ovirt.org/job/ovirt-engine-dashboard_4.0_build-artifacts-el7-x86_64/build?delay=0sec">http://jenkins.ovirt.org/job/ovirt-engine-dashboard_4.0_build-artifacts-el7-x86_64/build?delay=0sec</a><br></div><div><br></div><div>instead of: refs/heads/ovirt-engine-dashboard-1.0</div><div>put: refs/tags/ovirt-dashboard-tag (replace with real tag)</div><div><br></div><div>But i&#39;m not sure this will change the rpm name, you probably will need to change the job or create the official job for that...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Thanks,<br>
Vojtech<br>
<span class="im"><br>
<br>
----- Original Message -----<br>
&gt; From: &quot;Vojtech Szocs&quot; &lt;<a href="mailto:vszocs@redhat.com">vszocs@redhat.com</a>&gt;<br>
&gt; To: &quot;David Caro&quot; &lt;<a href="mailto:dcaro@redhat.com">dcaro@redhat.com</a>&gt;<br>
&gt; Cc: &quot;infra&quot; &lt;<a href="mailto:infra@ovirt.org">infra@ovirt.org</a>&gt;<br>
</span><div class=""><div class="h5">&gt; Sent: Wednesday, June 22, 2016 7:04:19 PM<br>
&gt; Subject: Re: [Jenkins] Passing parameters to build-artifacts.sh<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; &gt; From: &quot;David Caro&quot; &lt;<a href="mailto:dcaro@redhat.com">dcaro@redhat.com</a>&gt;<br>
&gt; &gt; To: &quot;Nir Soffer&quot; &lt;<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>&gt;<br>
&gt; &gt; Cc: &quot;infra&quot; &lt;<a href="mailto:infra@ovirt.org">infra@ovirt.org</a>&gt;<br>
&gt; &gt; Sent: Wednesday, June 22, 2016 6:31:44 PM<br>
&gt; &gt; Subject: Re: [Jenkins] Passing parameters to build-artifacts.sh<br>
&gt; &gt;<br>
&gt; &gt; On 06/22 19:21, Nir Soffer wrote:<br>
&gt; &gt; &gt; On Wed, Jun 22, 2016 at 6:47 PM, Barak Korren &lt;<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt; This could be done, but not trival to do, and also requires you to<br>
&gt; &gt; &gt; &gt; know,<br>
&gt; &gt; &gt; &gt; before merging, that this is the patch you are gonna release.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; A differnt but somewhat common practice is to use git tagging and &#39;git<br>
&gt; &gt; &gt; &gt; describe&#39; to set the package version.<br>
&gt; &gt; &gt; &gt; We can make build_artifacts trigger when a tag is pushed, AFAIK Lago<br>
&gt; &gt; &gt; &gt; already<br>
&gt; &gt; &gt; &gt; does that...<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; בתאריך 22 ביוני 2016 18:39,‏ &quot;Vojtech Szocs&quot; &lt;<a href="mailto:vszocs@redhat.com">vszocs@redhat.com</a>&gt; כתב:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;&gt; Hi,<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; I&#39;m just curious whether it&#39;s possible to do the following:<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; Let&#39;s say we have a project (ovirt-engine-dashboard) built by Jenkins,<br>
&gt; &gt; &gt; &gt;&gt; which means there&#39;s a Jenkins job that runs build-artifacts.sh script<br>
&gt; &gt; &gt; &gt;&gt; whenever a patch gets merged via gerrit.<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; Can we somehow pass custom parameters to build-artifacts.sh for such<br>
&gt; &gt; &gt; &gt;&gt; (Jenkins CI) builds?<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; For example, putting something like this into commit message:<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt;   My-Param 123<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; would reflect into `My-Param` env. variable when running the script?<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; Motivation: for release builds (which shouldn&#39;t contain the &quot;snapshot&quot;<br>
&gt; &gt; &gt; &gt;&gt; part [*] in RPM release string), pass parameter to build-artifacts.sh<br>
&gt; &gt; &gt; &gt;&gt; that ensures the &quot;snapshot&quot; part is empty. This way, we don&#39;t need to<br>
&gt; &gt; &gt; &gt;&gt; patch the project prior to release (remove &quot;snapshot&quot; in spec) &amp; then<br>
&gt; &gt; &gt; &gt;&gt; patch it again after the release (re-add &quot;snapshot&quot; in spec).<br>
&gt; &gt; &gt; &gt;&gt;<br>
&gt; &gt; &gt; &gt;&gt; [*] {date}git{commit}<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; How about adding a flag to the project yaml?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; For example:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;     version:<br>
&gt; &gt; &gt;       - master:<br>
&gt; &gt; &gt;           branch: master<br>
&gt; &gt; &gt;       - 0.16:<br>
&gt; &gt; &gt;           branch: ioprocess-0.16<br>
&gt; &gt; &gt;           release: true<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Then run build-artifacts with RELEASE=1 environment variable, so we can<br>
&gt; &gt; &gt; tell that this is a release build, and create release friendly rpms?<br>
&gt; &gt;<br>
&gt; &gt; That&#39;s not better than adding a commit to the project for each release imo.<br>
&gt; &gt;<br>
&gt; &gt; I&#39;d go for the tag thingie actually, just detecting that you are in a tag<br>
&gt; &gt; to<br>
&gt; &gt; control if the extra &#39;snapshot&#39; should be added or not.<br>
&gt;<br>
&gt; Yes, this sounds like the most correct approach. We&#39;ll need to tag anyway :)<br>
&gt;<br>
&gt; As mentioned above, it would be really nice if build-artifacts was invoked<br>
&gt; also when pushing new tag to remote.<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Nir<br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; Infra mailing list<br>
&gt; &gt; &gt; <a href="mailto:Infra@ovirt.org">Infra@ovirt.org</a><br>
&gt; &gt; &gt; <a href="http://lists.ovirt.org/mailman/listinfo/infra" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/infra</a><br>
&gt; &gt;<br>
&gt; &gt; --<br>
&gt; &gt; David Caro<br>
&gt; &gt;<br>
&gt; &gt; Red Hat S.L.<br>
&gt; &gt; Continuous Integration Engineer - EMEA ENG Virtualization R&amp;D<br>
&gt; &gt;<br>
&gt; &gt; Tel.: <a href="tel:%2B420%20532%20294%20605" value="+420532294605">+420 532 294 605</a><br>
&gt; &gt; Email: <a href="mailto:dcaro@redhat.com">dcaro@redhat.com</a><br>
&gt; &gt; IRC: dcaro|dcaroest@{freenode|oftc|redhat}<br>
&gt; &gt; Web: <a href="http://www.redhat.com" rel="noreferrer" target="_blank">www.redhat.com</a><br>
&gt; &gt; RHT Global #: 82-62605<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; Infra mailing list<br>
&gt; &gt; <a href="mailto:Infra@ovirt.org">Infra@ovirt.org</a><br>
&gt; &gt; <a href="http://lists.ovirt.org/mailman/listinfo/infra" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/infra</a><br>
&gt; &gt;<br>
&gt; _______________________________________________<br>
&gt; Infra mailing list<br>
&gt; <a href="mailto:Infra@ovirt.org">Infra@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/infra" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/infra</a><br>
&gt;<br>
_______________________________________________<br>
Infra mailing list<br>
<a href="mailto:Infra@ovirt.org">Infra@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/infra" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman/listinfo/infra</a><br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Eyal Edri<br>Associate Manager</div><div>RHEV DevOps<br>EMEA ENG Virtualization R&amp;D<br>Red Hat Israel<br><br>phone: +972-9-7692018<br>irc: eedri (on #tlv #rhev-dev #rhev-integ)</div></div></div></div></div>
</div></div>