On Fri, Feb 23, 2018 at 9:59 AM, Martin Perina <mper...@redhat.com> wrote:
> > > On Thu, Feb 22, 2018 at 8:41 PM, Yaniv Kaul <yk...@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 <d...@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. >>> >>> [1] http://jenkins.ovirt.org/ >>> >>> Thank you, >>> >>> Dafna >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Devel mailing list >>> de...@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> >> _______________________________________________ >> Devel mailing list >> de...@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)
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
