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

---------- Forwarded message ---------- From: <jenkins(a)jenkins.phx.ovirt.org&gt; Date: 15 November 2017 at 10:49 Subject: [oVirt Jenkins] standard-enqueue - Build #6908 - FAILURE! To: infra(a)ovirt.org Build: http://jenkins.ovirt.org/job/standard-enqueue/6908/ Build Name: #6908 Build Description: Gerrit: 84151 - ovirt-engine-api-metamodel (1.1) Build Status: FAILURE Gerrit change: https://gerrit.ovirt.org/84151 - title: [maven-release-plugin] prepare for next development iteration - project: ovirt-engine-api-metamodel - branch: metamodel_1.1 - author: Juan Hernandez <juan.hernandez(a)redhat.com&gt; _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

On 15 November 2017 at 15:57, Juan Hernández <jhernand(a)redhat.com&gt; 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.