[ovirt-devel] [JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse the artifacts built on check-merged if any

Eyal Edri eedri at redhat.com
Sun Nov 27 10:28:08 UTC 2016


Hi Vojtech,

I posted a patch [1] for this, so the change isn't merged yet.
We thought of using the 'minimal' macro for it.

Can you send your suggestion to the patch?


[1] https://gerrit.ovirt.org/#/c/67269/

On Fri, Nov 25, 2016 at 8:43 PM, Vojtech Szocs <vszocs at redhat.com> wrote:

> Hi,
>
> > Any patches sent on this?
>
> I'd like to help.
>
> Looking at the recent Engine (master) build:
>
>   http://jenkins.ovirt.org/job/ovirt-engine_master_build-
> artifacts-el7-x86_64/1691/
>
>   $ rpm -qlp ovirt-engine-webadmin-portal-4.1.0-0.0.master.
> 20161125171318.gitae69c34.el7.centos.noarch.rpm
>
> it shows we still build all [browser x language] GWT permutations,
> basically there are tons of <md5>.cache.js files in `webadmin.war`
> directory (each one represents a single permutation).
>
> In automation/build-artifacts.sh, we could add some variable that
> controls what kind of GWT build to do (e.g. GWT_BUILD_MODE):
>
> 1, snapshot GWT build: all supported browsers x en_US (only)
>    => 3 x 1 = 3 GWT permutations
>
> 2, full GWT build: all supported browsers x all supported locales
>    => 3 x 9 = 27 (!) GWT permutations
>
> With "snapshot GWT build", we should do:
>
>   rpmbuild \
>     .. existing stuff
>     -D "ovirt_build_locales 0" \
>     .. existing stuff
>
> GWT_BUILD_MODE can default to "full GWT build".
>
> But how do we override GWT_BUILD_MODE when doing non-release builds?
>
> Regards,
> Vojtech
>
>
> ----- Original Message -----
> > From: "eyal edri [Administrator] (oVirt JIRA)" <
> jira at ovirt-jira.atlassian.net>
> > To: infra at ovirt.org
> > Sent: Sunday, November 6, 2016 4:29:02 PM
> > Subject: [JIRA] (OVIRT-416) [standard-ci] build-artifacts should reuse
> the    artifacts built on check-merged if any
> >
> >
> >     [
> >     https://ovirt-jira.atlassian.net/browse/OVIRT-416?page=com.
> atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel&focusedCommentId=22321#comment-22321
> >     ]
> >
> > eyal edri [Administrator] commented on OVIRT-416:
> > -------------------------------------------------
> >
> > Any patches sent on this?
> > Also, wanted to mention #OVIRT-751 is handling similar purpose with
> enabling
> > better maven caching, so it might suffice as a starting point in
> optimizing
> > ovirt-engine runtime for builds.
> >
> > > [standard-ci] build-artifacts should reuse the artifacts built on
> > > check-merged if any
> > > ------------------------------------------------------------
> -------------------------
> > >
> > >                 Key: OVIRT-416
> > >                 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-416
> > >             Project: oVirt - virtualization made easy
> > >          Issue Type: Improvement
> > >            Reporter: David Caro Estevez
> > >            Assignee: infra
> > >
> > > Right now most projects just rebuild twice the artifacts, what for some
> > > means a big waste of resources, if we could just reuse what was built
> > > previously there would be no rebuilding.
> > > Something to take into account is that the distributions that
> check-merged
> > > and build-artifacts run for might not match, so you can be running
> > > check-merged only on fc23 but building artifacts for fc23, fc22 an el7
> (as
> > > an example), maybe we should not allow different distros on each
> stage?|
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v1000.499.4#100018)
> > _______________________________________________
> > Infra mailing list
> > Infra at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20161127/de7ed7b3/attachment-0001.html>


More information about the Devel mailing list