<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 26, 2016 at 7:37 PM, Vojtech Szocs <span dir="ltr"><<a href="mailto:vszocs@redhat.com" target="_blank">vszocs@redhat.com</a>></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) & all supported<br>
browsers (IE10+, Firefox, Chrome), by using `ovirt_build_locales 0`<br>
as the default fallback<br></blockquote><div><br></div><div>+1 from my side.</div><div>Sandro - any objections or thoughts?</div><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><div>You can make sure in the automation/ dir in the 'manual*' script has it.</div><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><div>In planning, what I want to do is to move the 'manual official' [1] to be automatic official builds,</div><div>as for RELEASE flag, we'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><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><div>Yea, see my comments.</div><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's original suggestion).<br></blockquote><div><br></div><div><br></div><div>Its currently on 'Rebase if necessary', if there is an agreement I can change it to 'Fast forward only'.</div><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 class="im HOEnZb"><br>
<br>
----- Original Message -----<br>
> From: "Nir Soffer" <<a href="mailto:nsoffer@redhat.com">nsoffer@redhat.com</a>><br>
> To: "Eyal Edri" <<a href="mailto:eedri@redhat.com">eedri@redhat.com</a>><br>
</span><div class="HOEnZb"><div class="h5">> Cc: "Juan Hernandez" <<a href="mailto:jhernand@redhat.com">jhernand@redhat.com</a>>, "devel" <<a href="mailto:devel@ovirt.org">devel@ovirt.org</a>>, "Martin Perina" <<a href="mailto:mperina@redhat.com">mperina@redhat.com</a>>, "Tal<br>
> Nisan" <<a href="mailto:tnisan@redhat.com">tnisan@redhat.com</a>>, "infra" <<a href="mailto:infra@ovirt.org">infra@ovirt.org</a>><br>
> Sent: Tuesday, September 20, 2016 5:38:08 PM<br>
> Subject: Re: Dropping rpm build from ovirt-engine check-merged.sh<br>
><br>
> On Tue, Sep 20, 2016 at 11:27 AM, Eyal Edri < <a href="mailto:eedri@redhat.com">eedri@redhat.com</a> > wrote:<br>
><br>
><br>
><br>
><br>
><br>
> On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola < <a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a> ><br>
> wrote:<br>
><br>
><br>
><br>
><br>
><br>
> On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri < <a href="mailto:eedri@redhat.com">eedri@redhat.com</a> > wrote:<br>
><br>
><br>
><br>
><br>
><br>
> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola < <a href="mailto:sbonazzo@redhat.com">sbonazzo@redhat.com</a> ><br>
> wrote:<br>
><br>
><br>
><br>
><br>
><br>
> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < <a href="mailto:eedri@redhat.com">eedri@redhat.com</a> > wrote:<br>
><br>
><br>
><br>
> Hi,<br>
><br>
> Following [1] I'd like to propose to remove rpm building from the<br>
> 'check-merged.sh' script from ovirt-engine (master for now).<br>
><br>
> The job [2] takes on avg 15 min while actually the rpms are built already in<br>
> check-patch<br>
> (with gwt draft mode if needed) and runs exactly the same build rpm command<br>
> as check-patch [3].<br>
><br>
> So there isn't real value in running exactly the same rpm build post merge,<br>
> and we already build full permutation mode in 'build-artifacts.sh'.<br>
><br>
> Any reason to keep it?<br>
> We can cut down valuable time in CI if we drop it and vacant more time for<br>
> more meaningful tests.<br>
><br>
><br>
> This depends on the flow: if we make check_merge gating to the merge and to<br>
> the build we should keep the rpm build becuase at merge a rebase is done<br>
> automatically.<br>
><br>
> What do you mean by 'gating to the merge'? I'm not sure I understand what it<br>
> means.<br>
> Isn't check-patch.sh does the gating? check-merge runs post merge so its<br>
> already too late to gate the code ...<br>
> And I think check-merge and check-patch currently runs the same rpmbuild<br>
> command, so I don't see how check-merged has any value over check-patch.<br>
><br>
> when merge command is issued a rebase is done as well. We still need a<br>
> check-merged job because the code checked by check-patch is not the same<br>
> anymore when check-merged runs.<br>
><br>
> OK, now I understand, so indeed check-merge can potentially run on different<br>
> code than check-patch and possibly fail due to it.<br>
><br>
> If we require only fast-forward merges, there is no way to merge patch<br>
> before a rebase. Once you rebase a patch, check-patch runs...<br>
><br>
> So check-merge may be unneeded in this case.<br>
><br>
><br>
><br>
><br>
><br>
><br>
> In original desing of stdci, check-merged was supposed to become a gating<br>
> test for build-artifacts.<br>
><br>
> We have it in our backlog, i.e installing Zuul and adding gating for the<br>
> check-merged jobs, its mostly relevant for system jobs, but we can defiently<br>
> do it first for simple 'check-merged.sh' jobs<br>
> as part of standard CI.<br>
><br>
> Opened a ticket for it [1]<br>
><br>
> [1] <a href="https://ovirt-jira.atlassian.net/browse/OVIRT-734" rel="noreferrer" target="_blank">https://ovirt-jira.atlassian.<wbr>net/browse/OVIRT-734</a><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> If there's not gating process performed by check-merge then I agree in<br>
> dropping rpm build.<br>
><br>
><br>
><br>
><br>
><br>
><br>
> [1] <a href="https://ovirt-jira.atlassian.net/browse/OVIRT-416" rel="noreferrer" target="_blank">https://ovirt-jira.atlassian.<wbr>net/browse/OVIRT-416</a><br>
> [2]<br>
> <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/<wbr>ovirt-engine_master_check-<wbr>merged-el7-x86_64/<wbr>buildTimeTrend</a><br>
> [3]<br>
> rpmbuild \<br>
> -D "_rpmdir $PWD/output" \<br>
> -D "_topmdir $PWD/rpmbuild" \<br>
> -D "release_suffix ${SUFFIX}" \<br>
> -D "ovirt_build_ut $BUILD_UT" \<br>
> -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \<br>
> -D "ovirt_build_draft 1" \<br>
> --rebuild output/*.src.rpm<br>
><br>
><br>
> --<br>
> Eyal Edri<br>
> Associate Manager<br>
> RHV DevOps<br>
> EMEA ENG Virtualization R&D<br>
> Red Hat Israel<br>
><br>
> phone: <a href="tel:%2B972-9-7692018" value="+97297692018">+972-9-7692018</a><br>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)<br>
><br>
><br>
><br>
> --<br>
> Sandro Bonazzola<br>
> Better technology. Faster innovation. Powered by community collaboration.<br>
> See how it works at <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Eyal Edri<br>
> Associate Manager<br>
> RHV DevOps<br>
> EMEA ENG Virtualization R&D<br>
> Red Hat Israel<br>
><br>
> phone: <a href="tel:%2B972-9-7692018" value="+97297692018">+972-9-7692018</a><br>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)<br>
><br>
><br>
><br>
> --<br>
> Sandro Bonazzola<br>
> Better technology. Faster innovation. Powered by community collaboration.<br>
> See how it works at <a href="http://redhat.com" rel="noreferrer" target="_blank">redhat.com</a><br>
><br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> --<br>
> Eyal Edri<br>
> Associate Manager<br>
> RHV DevOps<br>
> EMEA ENG Virtualization R&D<br>
> Red Hat Israel<br>
><br>
> phone: <a href="tel:%2B972-9-7692018" value="+97297692018">+972-9-7692018</a><br>
> irc: eedri (on #tlv #rhev-dev #rhev-integ)<br>
><br>
> ______________________________<wbr>_________________<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/<wbr>mailman/listinfo/infra</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<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/<wbr>mailman/listinfo/infra</a><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><div dir="ltr"><div>Eyal Edri<br>Associate Manager</div><div>RHV DevOps<br>EMEA ENG Virtualization R&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>
</div></div>