Re: Dropping rpm build from ovirt-engine check-merged.sh

[Sandro Bonazzola]

On Tue, Sep 27, 2016 at 2:40 PM, Eyal Edri <ee...@redhat.com> wrote:

>
>
> On Mon, Sep 26, 2016 at 7:37 PM, Vojtech Szocs <vsz...@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?
>

No objections provided that for release we can fix it.




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

Fast forward only will require lot of manual rebase. That's the reason we
dropped it in the past


>
>
>>
>> Regards,
>> Vojtech
>>
>>
>> - Original Message -
>> > From: "Nir Soffer" <nsof...@redhat.com>
>> > To: "Eyal Edri" <ee...@redhat.com>
>> > Cc: "Juan Hernandez" <jhern...@redhat.com>, "devel" <de...@ovirt.org>,
>> "Martin Perina" <mper...@redhat.com>, "Tal
>> > Nisan" <tni...@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 < ee...@redhat.com > wrote:
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola < sbona...@redhat.com
>> >
>> > wrote:
>> >
>> >
>> >
>> >
>> >
>> > On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri < ee...@redhat.com > wrote:
>> >
>> >
>> >
>> >
>> >
>> > On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola < sbona...@redhat.com
>> >
>> > wrote:
>> >
>> >
>> >
>> >
>> >
>> > On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < ee...@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.
>&

Re: Dropping rpm build from ovirt-engine check-merged.sh

[Eyal Edri]

On Mon, Sep 26, 2016 at 7:37 PM, Vojtech Szocs <vsz...@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" <nsof...@redhat.com>
> > To: "Eyal Edri" <ee...@redhat.com>
> > Cc: "Juan Hernandez" <jhern...@redhat.com>, "devel" <de...@ovirt.org>,
> "Martin Perina" <mper...@redhat.com>, "Tal
> > Nisan" <tni...@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 < ee...@redhat.com > wrote:
> >
> >
> >
> >
> >
> > On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola < sbona...@redhat.com
> >
> > wrote:
> >
> >
> >
> >
> >
> > On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri < ee...@redhat.com > wrote:
> >
> >
> >
> >
> >
> > On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola < sbona...@redhat.com
> >
> > wrote:
> >
> >
> >
> >
> >
> > On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < ee...@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

Re: Dropping rpm build from ovirt-engine check-merged.sh

[Vojtech Szocs]

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

  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)

- 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?)

Eyal/others, does above make sense?

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

Regards,
Vojtech


- Original Message -
> From: "Nir Soffer" <nsof...@redhat.com>
> To: "Eyal Edri" <ee...@redhat.com>
> Cc: "Juan Hernandez" <jhern...@redhat.com>, "devel" <de...@ovirt.org>, 
> "Martin Perina" <mper...@redhat.com>, "Tal
> Nisan" <tni...@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 < ee...@redhat.com > wrote:
> 
> 
> 
> 
> 
> On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola < sbona...@redhat.com >
> wrote:
> 
> 
> 
> 
> 
> On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri < ee...@redhat.com > wrote:
> 
> 
> 
> 
> 
> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola < sbona...@redhat.com >
> wrote:
> 
> 
> 
> 
> 
> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri < ee...@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

Re: Dropping rpm build from ovirt-engine check-merged.sh

[Nir Soffer]

On Tue, Sep 20, 2016 at 11:27 AM, Eyal Edri  wrote:

>
>
> On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri  wrote:
>>
>>>
>>>
>>> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola 
>>> wrote:
>>>


 On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri  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-m
> erged-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
> 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
>>> 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
> 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

Re: Dropping rpm build from ovirt-engine check-merged.sh

[Eyal Edri]

On Tue, Sep 20, 2016 at 9:34 AM, Sandro Bonazzola 
wrote:

>
>
> On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri  wrote:
>
>>
>>
>> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola 
>> wrote:
>>
>>>
>>>
>>> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri  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.


> 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-m
 erged-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
 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
>> 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
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

Re: Dropping rpm build from ovirt-engine check-merged.sh

[Sandro Bonazzola]

On Mon, Sep 19, 2016 at 7:56 PM, Eyal Edri  wrote:

>
>
> On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola 
> wrote:
>
>>
>>
>> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri  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.
In original desing of stdci, check-merged was supposed to become a gating
test for build-artifacts.




>
>
>> 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-m
>>> erged-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
>>> 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
> 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

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Dropping rpm build from ovirt-engine check-merged.sh

[Eyal Edri]

On Mon, Sep 19, 2016 at 9:41 AM, Sandro Bonazzola 
wrote:

>
>
> On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri  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.


> 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-m
>> erged-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
>> 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
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

Re: Dropping rpm build from ovirt-engine check-merged.sh

[Sandro Bonazzola]

On Sun, Sep 18, 2016 at 4:18 PM, Eyal Edri  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.



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

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra