[ovirt-devel] [ATN] [ACTION REQUIRED] Tweaking engine CI flow
Eyal Edri
eedri at redhat.com
Wed Mar 30 09:13:03 UTC 2016
On Wed, Mar 30, 2016 at 11:56 AM, David Caro <dcaro at redhat.com> wrote:
> On 03/30 11:45, Roy Golan wrote:
> > Hi all,
> >
> > Eyal and I sat together to analyse and tweak the engine CI and this is
> what
> > we came up with:
> >
> > - dao test excludes updated - exclude dal/src/main/bundles from invoking
> > dao tests
> > A trivial update of validation messages without any db change would
> > trigger dao test without any need. This is one less job run for lots of
> > patches.
> > This change is effective now.
>
> I really recommend merging this into the standard ci scripts and doing the
> trigger/don't trigger stuff there
>
Yea, thats the plan (discussed on another thread) but since it requires
some logic added of excluding certain path
we'll need to think how best to write it in check-patch.sh.
>
> >
> > - Spare CI re-run on trivial rebases
> > Gerrit trigger supports suppressing itself if the change to the tree
> was
> > trivial. Most of the waste of resources(time and IO :) ) is around
> > rebasing a change and waiting for CI to rerun. if Change1 is ci+1 and
> > Change2 is ci+1 the chances that they will break CI together is very
> small
> > and taking that risk is most probably worth it due to the huge resources
> > waste
>
> This is not exactly how it works, trivial rebases don't care if the
> previous
> patch had ci+1 or not, it just means that the rebase did not get any
> conflicts,
> that most of the time is not related to the tests working or not (it might
> be
> that someone change a method on another file, that your patch is using and
> it
> will be a trivial rebase and break the tests/compile).
>
Even so, I think its worth doing a test for a limited amount of time (1
week?)
while everyone is aware of it and to see if it cause errors, the chances
of 2 people working on the same file exactly during the same time and one
change failing another
is slim (If someone thinks otherwise and can give an example I'd be happy
to hear),
But since this is a gray area which we don't really know, I think its worth
the test.
>
> I don't really recommend skipping them. What you might meant is non-code
> changes, those are changes that only change the commit message, for
> example, if
> you have a patch, and you want to fix a typo in the commit message,
> currently
> that small commit message fix will require and trigger a ci run, while when
> skipping the non-code changes, it will not needed.
>
> > This change isn't effective yet - *Please reply here* if you agree or
> not
> > to make this change available.
> >
> > All of this is 'master' - 3.6 will follow if we will agree on activating
> > that change.
> >
> > Thanks,
> > Roy
>
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
>
>
> --
> David Caro
>
> Red Hat S.L.
> Continuous Integration Engineer - EMEA ENG Virtualization R&D
>
> Tel.: +420 532 294 605
> Email: dcaro at redhat.com
> IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> Web: www.redhat.com
> RHT Global #: 82-62605
>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
--
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160330/a3a2e177/attachment.html>
More information about the Infra
mailing list