On 11 January 2018 at 14:55, Viktor Mihajlovski
<mihajlov(a)linux.vnet.ibm.com> wrote:
On 07.01.2018 11:11, Barak Korren wrote:
[...]
>
> I looked into what happened there.
>
> It seems that Sandro added fc27 jobs a few weeks ago ago, and he also
> took the time to trigger the jobs manually to get an FC27 build.
>
> The issue is that this is not enough to get a build to properly go
> through the automated test and release processes,
>
> The CI system is build to respond on code changes. For most projects
> that is enough because new patches are merged frequently and as new
> jobs are added, patches show up soon after and trigger them.
>
> The root cause for this issue is that the set of platforms a project
> targets is currently maintained separately from the project's source
> code, so adding a new target platform is not always manifest in a code
> change to the project. We're working on resolving this by making the
> set of target platform be specified in the project's own source code.
> This would eventually mean that adding a new target platfrom will
> always require a patch to the project.
>
> For now, I've emulated a merge event on the latest patch to
> ovirt-vmconsole. This will cause the fc27 build (as well as others) to
> get recreated and pushed through the change-queue.
>
I think we face a similar problem for the s390x builds of ovirt-host.
Looks like the last changes to ovirt-host have been done before the
s390x fc27 jobs have been merged, so there are no s390x RPMS in the
repository.
Could you or someone else trigger a full ovirt-host build?
Done:
http://jenkins.ovirt.org/job/ovirt-host_master_build-artifacts-fc27-s390x/1/
The oVirt master change-queue is currently processing through some
regressions, so it might take a while for this to reach the repos.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. |
redhat.com/trusted