adding also infra team for visibility on the change in CI.
also inline.
On Fri, Dec 11, 2015 at 4:19 PM, Francesco Romani <fromani(a)redhat.com>
wrote:
> ----- Original Message -----
> > From: "Yaniv Bronheim" <ybronhei(a)redhat.com>
> > To: devel(a)ovirt.org, "Francesco Romani" <fromani(a)redhat.com>, "Nir
> Soffer" <nsoffer(a)redhat.com>, "Piotr Kliczewski"
> > <pkliczew(a)redhat.com>
> > Cc: "danken" <danken(a)redhat.com>, "David Caro" <dcaroest(a)redhat.com>,
> "Eyal Edri" <eedri(a)redhat.com>
> > Sent: Thursday, December 10, 2015 6:46:37 PM
> > Subject: Automation CI for vdsm
>
> [...]
> > We want to allow developers to trigger the script once reviews and
> > verification are ready (last step before merge). To do so we agreed to
> add
> > Continues Integration flag for each vdsm patch.
This flag will be called 'Workflow' or we can name it otherwise, we just
need to choose what makes sense.
David/Yaniv - Please correct me if I'm wrong.
> Once this flag will be
> > signed with +1 it will trigger Jenkins CI to run the check-merged script
> > (adding new button to gerrit is not an option - you can image that flag
> as
> > a trigger button), on success Jenkins CI flag will turn to +2. on fail
> > we'll get -1 and once new patchset is ready the developer will remove the
> > +1 and add it back to the Continues Integration flag to re-trigger the
> job.
> >
> > Please ack the process before we move on with that
>
> Sounds good, even though I'm a little scared (just gut feeling, no evidence
> whatsoever) that this could add even more complexity and fragility to the
> jenkins
> fleet.
>
> In the long run, when this is reliable, it will help greatly.
> In the short term, I'm scared because this can lead to false positives and
> bogus
> failures.
>
> Let me stress I don't have concrete item to share or specific flaws.
>
> As action item on me, I will find some time next week to check virt
> functional tests,
> to see if they need some fixes, work reliably and so forth
>
> > The patch for those scripts still under review and testing -
> > https://gerrit.ovirt.org/#/c/48268
>
> Will review asap.
>
> --
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani
>
--
Eyal Edri
Supervisor, RHEV CI
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)

Hi,
can we drop FC22 testing in jenkins now that FC23 jobs are up and running?
it will reduce jenkins load. If needed we can keep FC22 builds, just
dropping the check jobs.
Comments?
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

Hi all.
I wanted to bring up something that might make our work with CI a bit more
efficient.
As developers, we obviously use Jenkins in every step we are taking in the
developing process. Each patch that is pushed- or at least a big amount of
our patches- triggers Jenkins jobs automatically.
I can say that for myself, most of my push actions do not require any CI
jobs to run. Thus reviewing and updating patches include work that triggers
tons of redundant jobs that make the system slow for the jobs that are
actually needed..
I was thinking, maybe it would be better if we will explicitly require to
run the CI jobs when we push patches.. then only when the developer will
need the job's feedback it will be activated. no redundant jobs will run,
and we will wait much less for the jobs to finish when we will actually
need them.
Is that possible for implementation?
Thanks, Amit.