On Mon, Sep 26, 2016 at 7:37 PM, Vojtech Szocs <vszocs@redhat.com> wrote:

Hi,

to me, it seems that with current CI flow, we can do following:

- in build-artifacts.sh, build UI for English (only) & all supported
  browsers (IE10+, Firefox, Chrome), by using `ovirt_build_locales 0`
  as the default fallback

+1 from my side.

Sandro - any objections or thoughts?

 

  Note: this will cut down the # of permutations from 3x9 to just 3
  (currently we have 3 supported browser types, 9 supported locales).

- ensure that release builds still target all supported UI locales,
  by using `ovirt_build_locales 1` (override the default fallback)

You can make sure in the automation/ dir in the 'manual*' script has it.

 

- it would be nice if the Jenkins job for build-artifacts.sh would
  set some `RELEASE=1` flag (or similar) when doing a release build
  (is this possible with current standard CI?)

In planning, what I want to do is to move the 'manual official' [1] to be automatic official builds,

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 

an alternate way to avoid the manual patches for updating POM files.

 

Eyal/others, does above make sense?

Yea, see my comments.

 

Also, as Nir mentioned, if `ovirt-engine` repo was configured with
Submit Type == Fast Forward Only, we could drop RPM / GWT build in
check-merged.sh (which was Eyal's original suggestion).

Its currently on 'Rebase if necessary', if there is an agreement I can change it to 'Fast forward only'.

 

Regards,
Vojtech


----- Original Message -----
> From: "Nir Soffer" <nsoffer@redhat.com>
> To: "Eyal Edri" <eedri@redhat.com>

> Cc: "Juan Hernandez" <jhernand@redhat.com>, "devel" <devel@ovirt.org>, "Martin Perina" <mperina@redhat.com>, "Tal
> Nisan" <tnisan@redhat.com>, "infra" <infra@ovirt.org>
> Sent: Tuesday, September 20, 2016 5:38:08 PM
> Subject: Re: Dropping rpm build from ovirt-engine check-merged.sh
>
> On Tue, Sep 20, 2016 at 11:27 AM, Eyal Edri < eedri@redhat.com > wrote:
>
>
>
>
>
> On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola < sbonazzo@redhat.com >
> wrote:
>
>
>
>
>
> On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri < eedri@redhat.com > wrote:
>
>
>
>
>
> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola < sbonazzo@redhat.com >
> wrote:
>
>
>
>
>
> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < eedri@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.
>
> What do you mean by 'gating to the merge'? I'm not sure I understand what it
> means.
> Isn't check-patch.sh does the gating? check-merge runs post merge so its
> already too late to gate the code ...
> And I think check-merge and check-patch currently runs the same rpmbuild
> command, so I don't see how check-merged has any value over check-patch.
>
> when merge command is issued a rebase is done as well. We still need a
> check-merged job because the code checked by check-patch is not the same
> anymore when check-merged runs.
>
> OK, now I understand, so indeed check-merge can potentially run on different
> code than check-patch and possibly fail due to it.
>
> If we require only fast-forward merges, there is no way to merge patch
> before a rebase. Once you rebase a patch, check-patch runs...
>
> So check-merge may be unneeded in this case.
>
>
>
>
>
>
> In original desing of stdci, check-merged was supposed to become a gating
> test for build-artifacts.
>
> We have it in our backlog, i.e installing Zuul and adding gating for the
> check-merged jobs, its mostly relevant for system jobs, but we can defiently
> do it first for simple 'check-merged.sh' jobs
> as part of standard CI.
>
> Opened a ticket for it [1]
>
> [1] https://ovirt-jira.atlassian.net/browse/OVIRT-734
>
>
>
>
>
>
>
>
>
>
>
> If there's not gating process performed by check-merge then I agree in
> dropping rpm build.
>
>
>
>
>
>
> [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
>
>
>
>
> --
> 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
>
>
>
>

> --
> 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)
>
> _______________________________________________
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
>
> _______________________________________________
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>

--

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)