<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 2:40 PM, Eyal Edri <span dir="ltr">&lt;<a href="mailto:eedri@redhat.com" target="_blank">eedri@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Sep 26, 2016 at 7:37 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
to me, it seems that with current CI flow, we can do following:<br>
<br>
- in build-artifacts.sh, build UI for English (only) &amp; all supported<br>
  browsers (IE10+, Firefox, Chrome), by using `ovirt_build_locales 0`<br>
  as the default fallback<br></blockquote><div><br></div></span><div>+1 from my side.</div><div>Sandro - any objections or thoughts?</div></div></div></div></blockquote><div><br></div><div>No objections provided that for release we can fix it.</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  Note: this will cut down the # of permutations from 3x9 to just 3<br>
  (currently we have 3 supported browser types, 9 supported locales).<br>
<br>
- ensure that release builds still target all supported UI locales,<br>
  by using `ovirt_build_locales 1` (override the default fallback)<br></blockquote><div><br></div></span><div>You can make sure in the automation/ dir in the &#39;manual*&#39; script has it.</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- it would be nice if the Jenkins job for build-artifacts.sh would<br>
  set some `RELEASE=1` flag (or similar) when doing a release build<br>
  (is this possible with current standard CI?)<br></blockquote><div><br></div></span><div>In planning, what I want to do is to move the &#39;manual official&#39; [1] to be automatic official builds,</div><div>as for RELEASE flag, we&#39;ll need to discuss on changing how we manage ovirt-engine versioning, I think we talked about 4.1 or later to try to use mvn release plugin or </div><div>an alternate way to avoid the manual patches for updating POM files.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Eyal/others, does above make sense?<br></blockquote><div><br></div></span><div>Yea, see my comments.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, as Nir mentioned, if `ovirt-engine` repo was configured with<br>
Submit Type == Fast Forward Only, we could drop RPM / GWT build in<br>
check-merged.sh (which was Eyal&#39;s original suggestion).<br></blockquote><div><br></div><div><br></div></span><div>Its currently on &#39;Rebase if necessary&#39;, if there is an agreement I can change it to &#39;Fast forward only&#39;.</div></div></div></div></blockquote><div><br></div><div>Fast forward only will require lot of manual rebase. That&#39;s the reason we dropped it in the past</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
Vojtech<br>
<span><br>
<br>
----- Original Message -----<br>
&gt; From: &quot;Nir Soffer&quot; &lt;<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>&gt;<br>
&gt; To: &quot;Eyal Edri&quot; &lt;<a href="mailto:eedri@redhat.com" target="_blank">eedri@redhat.com</a>&gt;<br>
</span><div><div>&gt; Cc: &quot;Juan Hernandez&quot; &lt;<a href="mailto:jhernand@redhat.com" target="_blank">jhernand@redhat.com</a>&gt;, &quot;devel&quot; &lt;<a href="mailto:devel@ovirt.org" target="_blank">devel@ovirt.org</a>&gt;, &quot;Martin Perina&quot; &lt;<a href="mailto:mperina@redhat.com" target="_blank">mperina@redhat.com</a>&gt;, &quot;Tal<br>
&gt; Nisan&quot; &lt;<a href="mailto:tnisan@redhat.com" target="_blank">tnisan@redhat.com</a>&gt;, &quot;infra&quot; &lt;<a href="mailto:infra@ovirt.org" target="_blank">infra@ovirt.org</a>&gt;<br>
&gt; Sent: Tuesday, September 20, 2016 5:38:08 PM<br>
&gt; Subject: Re: Dropping rpm build from ovirt-engine check-merged.sh<br>
&gt;<br>
&gt; On Tue, Sep 20, 2016 at 11:27 AM, Eyal Edri &lt; <a href="mailto:eedri@redhat.com" target="_blank">eedri@redhat.com</a> &gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola &lt; <a href="mailto:sbonazzo@redhat.com" target="_blank">sbonazzo@redhat.com</a> &gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri &lt; <a href="mailto:eedri@redhat.com" target="_blank">eedri@redhat.com</a> &gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola &lt; <a href="mailto:sbonazzo@redhat.com" target="_blank">sbonazzo@redhat.com</a> &gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri &lt; <a href="mailto:eedri@redhat.com" target="_blank">eedri@redhat.com</a> &gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Hi,<br>
&gt;<br>
&gt; Following [1] I&#39;d like to propose to remove rpm building from the<br>
&gt; &#39;check-merged.sh&#39; script from ovirt-engine (master for now).<br>
&gt;<br>
&gt; The job [2] takes on avg 15 min while actually the rpms are built already in<br>
&gt; check-patch<br>
&gt; (with gwt draft mode if needed) and runs exactly the same build rpm command<br>
&gt; as check-patch [3].<br>
&gt;<br>
&gt; So there isn&#39;t real value in running exactly the same rpm build post merge,<br>
&gt; and we already build full permutation mode in &#39;build-artifacts.sh&#39;.<br>
&gt;<br>
&gt; Any reason to keep it?<br>
&gt; We can cut down valuable time in CI if we drop it and vacant more time for<br>
&gt; more meaningful tests.<br>
&gt;<br>
&gt;<br>
&gt; This depends on the flow: if we make check_merge gating to the merge and to<br>
&gt; the build we should keep the rpm build becuase at merge a rebase is done<br>
&gt; automatically.<br>
&gt;<br>
&gt; What do you mean by &#39;gating to the merge&#39;? I&#39;m not sure I understand what it<br>
&gt; means.<br>
&gt; Isn&#39;t check-patch.sh does the gating? check-merge runs post merge so its<br>
&gt; already too late to gate the code ...<br>
&gt; And I think check-merge and check-patch currently runs the same rpmbuild<br>
&gt; command, so I don&#39;t see how check-merged has any value over check-patch.<br>
&gt;<br>
&gt; when merge command is issued a rebase is done as well. We still need a<br>
&gt; check-merged job because the code checked by check-patch is not the same<br>
&gt; anymore when check-merged runs.<br>
&gt;<br>
&gt; OK, now I understand, so indeed check-merge can potentially run on different<br>
&gt; code than check-patch and possibly fail due to it.<br>
&gt;<br>
&gt; If we require only fast-forward merges, there is no way to merge patch<br>
&gt; before a rebase. Once you rebase a patch, check-patch runs...<br>
&gt;<br>
&gt; So check-merge may be unneeded in this case.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; In original desing of stdci, check-merged was supposed to become a gating<br>
&gt; test for build-artifacts.<br>
&gt;<br>
&gt; We have it in our backlog, i.e installing Zuul and adding gating for the<br>
&gt; check-merged jobs, its mostly relevant for system jobs, but we can defiently<br>
&gt; do it first for simple &#39;check-merged.sh&#39; jobs<br>
&gt; as part of standard CI.<br>
&gt;<br>
&gt; Opened a ticket for it [1]<br>
&gt;<br>
&gt; [1] <a href="https://ovirt-jira.atlassian.net/browse/OVIRT-734" rel="noreferrer" target="_blank">https://ovirt-jira.atlassian.n<wbr>et/browse/OVIRT-734</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; If there&#39;s not gating process performed by check-merge then I agree in<br>
&gt; dropping rpm build.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; [1] <a href="https://ovirt-jira.atlassian.net/browse/OVIRT-416" rel="noreferrer" target="_blank">https://ovirt-jira.atlassian.n<wbr>et/browse/OVIRT-416</a><br>
&gt; [2]<br>
&gt; <a href="http://jenkins.ovirt.org/job/ovirt-engine_master_check-merged-el7-x86_64/buildTimeTrend" rel="noreferrer" target="_blank">http://jenkins.ovirt.org/job/o<wbr>virt-engine_master_check-merge<wbr>d-el7-x86_64/buildTimeTrend</a><br>
&gt; [3]<br>
&gt; rpmbuild \<br>
&gt; -D &quot;_rpmdir $PWD/output&quot; \<br>
&gt; -D &quot;_topmdir $PWD/rpmbuild&quot; \<br>
&gt; -D &quot;release_suffix ${SUFFIX}&quot; \<br>
&gt; -D &quot;ovirt_build_ut $BUILD_UT&quot; \<br>
&gt; -D &quot;ovirt_build_extra_flags $EXTRA_BUILD_FLAGS&quot; \<br>
&gt; -D &quot;ovirt_build_draft 1&quot; \<br>
&gt; --rebuild output/*.src.rpm<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Eyal Edri<br>
&gt; Associate Manager<br>
&gt; RHV DevOps<br>
&gt; EMEA ENG Virtualization R&amp;D<br>
&gt; Red Hat Israel<br>
&gt;<br>
&gt; phone: <a href="tel:%2B972-9-7692018" value="+97297692018" target="_blank">+972-9-7692018</a><br>
&gt; irc: eedri (on #tlv #rhev-dev #rhev-integ)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Sandro Bonazzola<br>
&gt; Better technology. Faster innovation. Powered by community collaboration.<br>
&gt; See how it works at <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Eyal Edri<br>
&gt; Associate Manager<br>
&gt; RHV DevOps<br>
&gt; EMEA ENG Virtualization R&amp;D<br>
&gt; Red Hat Israel<br>
&gt;<br>
&gt; phone: <a href="tel:%2B972-9-7692018" value="+97297692018" target="_blank">+972-9-7692018</a><br>
&gt; irc: eedri (on #tlv #rhev-dev #rhev-integ)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Sandro Bonazzola<br>
&gt; Better technology. Faster innovation. Powered by community collaboration.<br>
&gt; See how it works at <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
</div></div><div><div>&gt; --<br>
&gt; Eyal Edri<br>
&gt; Associate Manager<br>
&gt; RHV DevOps<br>
&gt; EMEA ENG Virtualization R&amp;D<br>
&gt; Red Hat Israel<br>
&gt;<br>
&gt; phone: <a href="tel:%2B972-9-7692018" value="+97297692018" target="_blank">+972-9-7692018</a><br>
&gt; irc: eedri (on #tlv #rhev-dev #rhev-integ)<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Infra mailing list<br>
&gt; <a href="mailto:Infra@ovirt.org" target="_blank">Infra@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/infra" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/infra</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Infra mailing list<br>
&gt; <a href="mailto:Infra@ovirt.org" target="_blank">Infra@ovirt.org</a><br>
&gt; <a href="http://lists.ovirt.org/mailman/listinfo/infra" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/infra</a><br>
&gt;<br>
</div></div></blockquote></div></div></div><div><div class="h5"><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Eyal Edri<br>Associate Manager</div><div>RHV DevOps<br>EMEA ENG Virtualization R&amp;D<br>Red Hat Israel<br><br>phone: <a href="tel:%2B972-9-7692018" value="+97297692018" target="_blank">+972-9-7692018</a><br>irc: eedri (on #tlv #rhev-dev #rhev-integ)</div></div></div></div></div></div></div>
</div></div></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><div dir="ltr">Sandro Bonazzola<br>Better technology. Faster innovation. Powered by community collaboration.<br>See how it works at <a href="http://redhat.com" target="_blank">redhat.com</a><br></div></div><div dir="ltr"><a href="https://www.redhat.com/it/about/events/red-hat-open-source-day-2016" target="_blank"><img src="http://images.engage.redhat.com/EloquaImages/clients/RedHat/%7B53f97a34-013e-4b79-966f-222f50a6de8c%7D_Red_Hat_Open_Source_Day_2_CITIES.png" width="420" height="60"></a><br></div></div></div></div></div>
</div></div>