Fwd: [oVirt Jenkins] standard-enqueue - Build #6908 - FAILURE!

Juan Hernández jhernand at redhat.com
Wed Nov 15 14:47:56 UTC 2017


On 11/15/2017 03:24 PM, Barak Korren wrote:
> On 15 November 2017 at 15:57, Juan Hernández <jhernand at redhat.com> wrote:
>> On 11/15/2017 02:33 PM, Barak Korren wrote:
>>>
>>> Hi Juan,
>>>
>>> What is the point of the
>>> 'ovirt-engine-api-metamodel_1.1_build-artifacts-*' jobs?
>>>
>>> For post-merge jobs, the 'version' part of the job names is supposed
>>> to refer to an oVirt version.
>>> We keep getting errors like the one below because the system is trying
>>> to 'release' the package into a non-existent oVirt version (1.1 in
>>> this case)...
>>>
>>
>> The version part of those jobs is the version of the project, the
>> `ovirt-egnine-api-metamodel` project in this case. Why should it be the
>> version of the `ovirt-engine` project?
> 
> This is the version of oVirt itself, as a whole, It is similar to the
> version of 'ovirt-engine' but may not be identical.
> 
> It needs to be the version of oVirt, because this is how the system
> knows along with which oVirt release should your artifacts be
> released.
> 
> This has no implication for the branch names in individual projects
> because you can map thing however you like.
> 
>> If the version needs to be the version of the `ovirt-engine` project we can
>> change it, but doesn't seem right to me.
> 
> Again, think of it as the oVirt version you target.
> 

OK, no problem, I will change that.

>> Note also that these jobs don't produce anything that needs to be released
>> as part of the oVirt project. The artifacts are released via Maven Central,
>> and used only during build time of the engine and the SDKs.
> 
> I see, well, we will add a way to specify if you have artifacts to
> release or not soon, you can already see this working in ovirt-ansible
> (specified in automation.yaml), but it'll take some time for us to
> port support for this from GitHub to Gerrit.
> 



More information about the Infra mailing list