[ovirt-devel] Dropping rpm build from ovirt-engine check-merged.sh

[Eyal Edri]

On Mon, Sep 19, 2016 at 6:49 PM, Vojtech Szocs <vszocs at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Sandro Bonazzola" <sbonazzo at redhat.com>
> > To: "Eyal Edri" <eedri at redhat.com>
> > Cc: "Juan Hernandez" <jhernand at redhat.com>, "infra" <infra at ovirt.org>,
> "devel" <devel at ovirt.org>
> > Sent: Monday, September 19, 2016 8:41:12 AM
> > Subject: Re: [ovirt-devel] Dropping rpm build from ovirt-engine
>  check-merged.sh
> >
> >
> >
> > On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < eedri at redhat.com > wrote:
> >
> >
> >
> > Hi,
> >
> > Following [1] I'd like to propose to remove rpm building from the
> > 'check-merged.sh' script from ovirt-engine (master for now).
> >
> > The job [2] takes on avg 15 min while actually the rpms are built
> already in
> > check-patch
> > (with gwt draft mode if needed) and runs exactly the same build rpm
> command
> > as check-patch [3].
> >
> > So there isn't real value in running exactly the same rpm build post
> merge,
> > and we already build full permutation mode in 'build-artifacts.sh'.
> >
> > Any reason to keep it?
> > We can cut down valuable time in CI if we drop it and vacant more time
> for
> > more meaningful tests.
> >
> >
> > This depends on the flow: if we make check_merge gating to the merge and
> to
> > the build we should keep the rpm build becuase at merge a rebase is done
> > automatically.
> > If there's not gating process performed by check-merge then I agree in
> > dropping rpm build.
>
> First of all, for oVirt Engine snapshot (non-release) builds, we should
> avoid doing a full GWT compilation [all browsers x all locales]. That's
> simply because the full GWT compilation is too costly for CI to run on
> a regular basis.
>

+1, It also makes us find regressions slower because it takes more than 1
hour to build + consume very valuable resource which is BM slave.


>
> Doing [Firefox + Chrome x English = 2 permutations] && [draft GWT build
> option enabled] for snapshot builds should be enough.
>
> The *only* downside of not doing a full GWT build is that problems with
> localization resources [e.g. non-English .properties files] will not be
> reported by the GWT compiler. But we have Java unit tests to cover this,
> so it should be OK. (And if not, we must improve those tests.)
>
> In general, we should do a full GWT compilation only for release builds.
> Eyal mentioned at [1] that his team is working on
>
>   'build official manual' option to standard CI
>

Already merged and working for most projects.who requested it, also part of
standard CI.


>
> so that would be a great place to document & perform the full GWT build.
>
> As for build jobs: if `check-merged` is indeed acting as gate for merge
> [fail of `check-merged` => patch not merged


its not the case today, we'll need to install Zuul for that, which is in
the plan (including system tests).


> , `build-artifacts` does not
> execute], then it actually makes sense to:
>
> - keep `check-merged` doing a (draft) GWT build + Engine RPM build
> - maybe skip GWT build in `check-patch` [right now, there's detection
>   logic => if frontend files were changed, do GWT build]
>
> Otherwise, if `check-merged` doesn't act as gate for merge, we can just
> skip GWT build / Engine RPM build for that script.
>

Yea, doesn't act as gate, it just run post merge.


>
> >
> >
> >
> >
> >
> >
> > [1] https://ovirt-jira.atlassian.net/browse/OVIRT-416
> > [2]
> > http://jenkins.ovirt.org/job/ovirt-engine_master_check-
> merged-el7-x86_64/buildTimeTrend
> > [3]
> > rpmbuild \
> > -D "_rpmdir $PWD/output" \
> > -D "_topmdir $PWD/rpmbuild" \
> > -D "release_suffix ${SUFFIX}" \
> > -D "ovirt_build_ut $BUILD_UT" \
> > -D "ovirt_build_extra_flags $EXTRA_BUILD_FLAGS" \
> > -D "ovirt_build_draft 1" \
> > --rebuild output/*.src.rpm
> >
> >
> > --
> > Eyal Edri
> > Associate Manager
> > RHV DevOps
> > EMEA ENG Virtualization R&D
> > Red Hat Israel
> >
> > phone: +972-9-7692018
> > irc: eedri (on #tlv #rhev-dev #rhev-integ)
> >
> >
> >
> > --
> > Sandro Bonazzola
> > Better technology. Faster innovation. Powered by community collaboration.
> > See how it works at redhat.com
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
>



-- 
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160919/53271392/attachment-0001.html>