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: [image: 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. 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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/devel

On Thu, Feb 22, 2018 at 8:41 PM, Yaniv Kaul <ykaul(a)redhat.com&gt; 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(a)redhat.com&gt; 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: >> >> [image: 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​ ...

>> 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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > > _______________________________________________ > Devel mailing list > Devel(a)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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra