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(a)redhat.com> wrote:
> On Wed, Jan 17, 2018 at 5:41 PM Eyal Edri <eedri(a)redhat.com> wrote:
>
>> On Wed, Jan 17, 2018 at 5:38 PM, Eyal Edri <eedri(a)redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, Jan 17, 2018 at 5:23 PM, Nir Soffer <nsoffer(a)redhat.com>
wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jan 17, 2018 at 5:08 PM Barak Korren <bkorren(a)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-x8...
>>>
>>
>> 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(a)ovirt.org
>>>>
http://lists.ovirt.org/mailman/listinfo/infra
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Eyal edri
>>>
>>>
>>> MANAGER
>>>
>>> RHV DevOps
>>>
>>> EMEA VIRTUALIZATION R&D
>>>
>>>
>>> Red Hat EMEA <
https://www.redhat.com/>
>>> <
https://red.ht/sig> TRIED. TESTED. TRUSTED.
>>> <
https://redhat.com/trusted>
>>> phone: +972-9-7692018 <+972%209-769-2018>
>>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>>
>>
>>
>>
>> --
>>
>> Eyal edri
>>
>>
>> MANAGER
>>
>> RHV DevOps
>>
>> EMEA VIRTUALIZATION R&D
>>
>>
>> Red Hat EMEA <
https://www.redhat.com/>
>> <
https://red.ht/sig> TRIED. TESTED. TRUSTED.
>> <
https://redhat.com/trusted>
>> phone: +972-9-7692018 <+972%209-769-2018>
>> irc: eedri (on #tlv #rhev-dev #rhev-integ)
>>
>