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

[Barak Korren]

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.

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

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