The importance of fixing failed build-artifacts jobs
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
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:
[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.
Thank you,
Dafna
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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:
[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.
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.
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:
[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 ...
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.
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 <https://www.redhat.com/> <https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted> phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
participants (4)
-
Dafna Ron -
Eyal Edri -
Martin Perina -
Yaniv Kaul