On Wed, Jan 17, 2018 at 7:15 PM Nir Soffer <nsoffer@redhat.com> wrote:

Thanks for reporting this issue, should be fixed by

https://gerrit.ovirt.org/#/c/86489/

Can someone trigger build artifacts job to test this patch?

Can I trigger build-artifacts job manually?

Ok, found how to do this.

The issue here is empty release_suffix - this happens only when 

we build a release version from tag. This the reason we did

not find this issue before, and we cannot detect this issue 

by running build-artifacts on each build, unless we add a special

test to tag the local checkout, and build from the tag.

Daniel, lets merge it and push a new tag to check if the build

works.

 

On Wed, Jan 17, 2018 at 6:39 PM Nir Soffer <nsoffer@redhat.com> wrote:

On Wed, Jan 17, 2018 at 5:41 PM Eyal Edri <eedri@redhat.com> wrote:

On Wed, Jan 17, 2018 at 5:38 PM, Eyal Edri <eedri@redhat.com> wrote:

On Wed, Jan 17, 2018 at 5:23 PM, Nir Soffer <nsoffer@redhat.com> wrote:

On Wed, Jan 17, 2018 at 5:08 PM Barak Korren <bkorren@redhat.com> wrote:

Hi Guys,

I'm sure you are aware that 'ovirt-imageio' is currently failing to
build on FC27 and Rawhide.

Why are you sure? I never seen any build failure since we added the 

fc27 and fcraw builds.

Please point us to failed builds.

Latest one - http://jenkins.ovirt.org/job/ovirt-imageio_master_build-artifacts-fc27-x86_64/32/

If it doesn't take too long, I think its worth adding building RPMs to check-patch as well, so you can catch such errors 

before the merge.

This is certainly what we need to do.

 

 

 

 

I'm not sure you get the implications tough.

The 1st thing that the release change-queue is checking, before
running OST, is if all builds for all patches it is checking are
building successfully for all platforms that the project has jobs for.

This means that essentially no new 'ovirt-imageio' packages are making
it into the tested and nightly repos for __any__ platform.

Furthermore, with the way the system works for now, there is no
special handling for build failures, with means they are treated like
OST failures, which means the system runs an expensive bisection
search to find the failing patch. So when your project fails to build,
it slows down checking for other project's patches.

I ask that you please do one of the following:
1. Fix the FC27 and RAWHIDE builds
2. Remove the FC27 and RAWHIDE build jobs
3. Turn the FC27 and RAWHIDE build jobs into check-merged jobs which
are not checked by the change-queue.

--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

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

--

Eyal edri

MANAGER

RHV DevOps

EMEA VIRTUALIZATION R&D

Red Hat EMEA

TRIED. TESTED. TRUSTED.

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)

--

Eyal edri

MANAGER

RHV DevOps

EMEA VIRTUALIZATION R&D

Red Hat EMEA

TRIED. TESTED. TRUSTED.

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)