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

[Vojtech Szocs]

----- 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.

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

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, `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.

> 
> 
> 
> 
> 
> 
> [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