On Fri, Feb 23, 2018 at 9:59 AM, Martin Perina <mperina@redhat.com> wrote:


On Thu, Feb 22, 2018 at 8:41 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
I think there's a rush to add FC27 and S390 (unrelated?) to the build. If either fail, right now, I don't think we should be too concerned with them.
In the very near future we should be, though.
Y.

On Thu, Feb 22, 2018 at 9:06 PM, Dafna Ron <dron@redhat.com> wrote:
Hi All,

We have been seeing a large amount of changes that are not deployed into tested lately because of failed build-artifacts jobs so we decided that perhaps we need to explain the importance of fixing a failed build-artifacts job.

If a change failed a build-artifacts job, no matter what platform/arch it failed in, the change will not be deployed to tested.

Here is an example of a change that will not be added to tested:

Inline image 1

As you can see, only one of the build-artifacts jobs failed but since the project specify that it requires all of these arches/platforms, the change will not be added to tested until all of the jobs are fixed.

​Is there a way how to identify the distribution as "not mandatory"? I mean we want the build, but it fails it should not affect the whole flow. That would really help with fcraw issues, because it's expected that things will often be broken there​ ...

I don't think there is an option currently to have "non-mandatory" distro, the only way I can think of will be to add the new distro to 'check-patch' so it will test it, but don't add it to 'build-artifacts' if you're not 100% sure its supported and working
This way you'll keep testing new OS, but won't block deployments if its not building yet. 
 


So what can we do?

1. Add the code which builds-artifacts to 'check-patch' so you'll get a -1 if a build failed (assuming you will not merge with -1 from CI).
2. post merge - look for emails on failed artifacts on your change (you will have to fix the job and then re-trigger the change)
3. you can see all current broken failed artifacts jobs in jenkins under 'unstable critical' view [1] and you will know if your project is being deployed.
4. Remove the broken OS from your project ( either from Jenkins or from your automation dir if you're using V2 ) - ask us for help! this should be an easy patch
5.Don't add new OS builds until you're absolutly sure they work ( you can add check-patch to keep testing it, but don't add build-artifacts until its stable ).

Please contact myself or anyone else from the CI team for assistance or questions and we would be happy to help.

[1] http://jenkins.ovirt.org/

Thank you,

Dafna






_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel


_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel



--
Martin Perina
Associate Manager, Software Engineering
Red Hat Czech s.r.o.

_______________________________________________
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra




--

Eyal edri


MANAGER

RHV DevOps

EMEA VIRTUALIZATION R&D


Red Hat EMEA

TRIED. TESTED. TRUSTED.
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)