stopping/aborting obsolete jenkins jobs

Hi, It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them. Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset? This will both give quicker results for the dev/maint and lower the load on the slaves. Best, -- Didi

----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs
Hi,
It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them.
Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset?
Happens to me a lot I think that it should be automatic and if you are pushing version x+1 then if version x jobs are still running , it will be aborted
This will both give quicker results for the dev/maint and lower the load on the slaves.
Best, -- Didi _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

--sLx0z+5FKKtIVDwd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 05/05, Eli Mesika wrote:
=20 =20 ----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs =20 Hi, =20 It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, i= n some cases even before it started running some of them. =20 Perhaps in such a case we should stop (if running) or disable/abort (if= not yet running) all the jobs except for the ones running for the latest patchs= et? =20 =20 Happens to me a lot=20 I think that it should be automatic and if you are pushing version x+1 th= en if version x jobs are still running , it will be aborted=20
Afaik, that behavior is only supported by zuul. So not something that we can easily change.
=20 =20
=20 This will both give quicker results for the dev/maint and lower the loa= d on the slaves. =20 Best, -- Didi _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra =20
Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --sLx0z+5FKKtIVDwd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVSHD9AAoJEEBxx+HSYmnDHpMH/R3PI1LBMML8ly52ld8R+EcS xnagjpTOW/sp6VegmPflHRnI0j2Rlgsa6UjMVGJl14l0Q+dqZ0k7nwFfzl6kEaii h2Gdq0xqCVM1mrX8h0r9hBzC36kM1kYfaxHwWW8gLhjQVnHxLrnhjvtmFWOmj6RJ 8eWmP1yrkik2uoh2uzjvAY1pCLqg1R+Wyf7YdhmIfCqKiOaDS4lQuWricJNs1jxY 6ahXHBHzWLV4Gv8ijASDPlPymehGyGMZCyonA8uwsvioyFIGfd4yp+xXAinxCySm HYdnkhcT1jB2Oyx0Na+gL876Ovn68Ucn/8zywYS+fH4Iz6YIyTzy8BPxctjpuME= =aOD/ -----END PGP SIGNATURE----- --sLx0z+5FKKtIVDwd--

----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs
Hi,
It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them.
Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset?
not sure its possible, but its not something that you want to do (aggressive interrupt jenkins running or queue)
This will both give quicker results for the dev/maint and lower the load on the slaves.
we are working on improving this on 2 fronts: 1. adding more slaves 2. reducing job running time (findbugs is currently being optimized) and you're welcome to join the effort of getting there next monday, on the infra hackathon :) [1] [1] https://docs.google.com/spreadsheets/d/1PGGqI5tT_pmF7HUdg63FlozuVoQOBQaO-VID...
Best, -- Didi _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 10:15:21 AM Subject: Re: stopping/aborting obsolete jenkins jobs
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs
Hi,
It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them.
Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset?
not sure its possible, but its not something that you want to do (aggressive interrupt jenkins running or queue)
This will both give quicker results for the dev/maint and lower the load on the slaves.
we are working on improving this on 2 fronts: 1. adding more slaves 2. reducing job running time (findbugs is currently being optimized)
forgot one more thing - we added a new flag called 'workflow' which we are testing now on the jenkins project. this flag means that the developer marks: "my code is ready for review" (might not be verified yet, since he wants early engagement before running a verification). For jenkins it means that only when a developer will mark +1 on this patch the jenkins jobs will start running on it (instead of running per patchset). so if we're OK in adding this flag to engine/vdsm - it will reduce dramatically the amount of running jobs.
and you're welcome to join the effort of getting there next monday, on the infra hackathon :) [1]
[1] https://docs.google.com/spreadsheets/d/1PGGqI5tT_pmF7HUdg63FlozuVoQOBQaO-VID...
Best, -- Didi _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 10:19:57 AM Subject: Re: stopping/aborting obsolete jenkins jobs
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 10:15:21 AM Subject: Re: stopping/aborting obsolete jenkins jobs
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs
Hi,
It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them.
Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset?
not sure its possible, but its not something that you want to do (aggressive interrupt jenkins running or queue)
This will both give quicker results for the dev/maint and lower the load on the slaves.
we are working on improving this on 2 fronts: 1. adding more slaves 2. reducing job running time (findbugs is currently being optimized)
forgot one more thing - we added a new flag called 'workflow' which we are testing now on the jenkins project. this flag means that the developer marks: "my code is ready for review" (might not be verified yet, since he wants early engagement before running a verification). For jenkins it means that only when a developer will mark +1 on this patch the jenkins jobs will start running on it (instead of running per patchset).
so if we're OK in adding this flag to engine/vdsm - it will reduce dramatically the amount of running jobs.
+1 , I am totally for it, we are waiting ages for tests completion so this flag will be great ...
and you're welcome to join the effort of getting there next monday, on the infra hackathon :) [1]
[1] https://docs.google.com/spreadsheets/d/1PGGqI5tT_pmF7HUdg63FlozuVoQOBQaO-VID...
Best, -- Didi _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

----- Original Message -----
From: "Eli Mesika" <emesika@redhat.com> To: "Eyal Edri" <eedri@redhat.com> Cc: "Yedidyah Bar David" <didi@redhat.com>, "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 1:42:47 PM Subject: Re: stopping/aborting obsolete jenkins jobs
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 10:19:57 AM Subject: Re: stopping/aborting obsolete jenkins jobs
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 10:15:21 AM Subject: Re: stopping/aborting obsolete jenkins jobs
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs
Hi,
It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them.
Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset?
not sure its possible, but its not something that you want to do (aggressive interrupt jenkins running or queue)
This will both give quicker results for the dev/maint and lower the load on the slaves.
we are working on improving this on 2 fronts: 1. adding more slaves 2. reducing job running time (findbugs is currently being optimized)
forgot one more thing - we added a new flag called 'workflow' which we are testing now on the jenkins project. this flag means that the developer marks: "my code is ready for review" (might not be verified yet, since he wants early engagement before running a verification). For jenkins it means that only when a developer will mark +1 on this patch the jenkins jobs will start running on it (instead of running per patchset).
so if we're OK in adding this flag to engine/vdsm - it will reduce dramatically the amount of running jobs.
+1 , I am totally for it, we are waiting ages for tests completion so this flag will be great ...
for the immediate time, we can also restrict jobs to run only on +verified or +1, this is one of the tasks for next week's hackathon.
and you're welcome to join the effort of getting there next monday, on the infra hackathon :) [1]
[1] https://docs.google.com/spreadsheets/d/1PGGqI5tT_pmF7HUdg63FlozuVoQOBQaO-VID...
Best, -- Didi _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

Il 05/05/2015 12:42, Eli Mesika ha scritto:
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 10:19:57 AM Subject: Re: stopping/aborting obsolete jenkins jobs
----- Original Message -----
From: "Eyal Edri" <eedri@redhat.com> To: "Yedidyah Bar David" <didi@redhat.com> Cc: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 10:15:21 AM Subject: Re: stopping/aborting obsolete jenkins jobs
----- Original Message -----
From: "Yedidyah Bar David" <didi@redhat.com> To: "Infra" <infra@ovirt.org> Sent: Tuesday, May 5, 2015 8:26:43 AM Subject: stopping/aborting obsolete jenkins jobs
Hi,
It happened to me quite a lot lately, that I pushed a new patchset for a change, before jenkins finished running relevant jobs for previous patchsets, in some cases even before it started running some of them.
Perhaps in such a case we should stop (if running) or disable/abort (if not yet running) all the jobs except for the ones running for the latest patchset?
not sure its possible, but its not something that you want to do (aggressive interrupt jenkins running or queue)
This will both give quicker results for the dev/maint and lower the load on the slaves.
we are working on improving this on 2 fronts: 1. adding more slaves 2. reducing job running time (findbugs is currently being optimized)
forgot one more thing - we added a new flag called 'workflow' which we are testing now on the jenkins project. this flag means that the developer marks: "my code is ready for review" (might not be verified yet, since he wants early engagement before running a verification). For jenkins it means that only when a developer will mark +1 on this patch the jenkins jobs will start running on it (instead of running per patchset).
so if we're OK in adding this flag to engine/vdsm - it will reduce dramatically the amount of running jobs.
+1 , I am totally for it, we are waiting ages for tests completion so this flag will be great ...
+1
and you're welcome to join the effort of getting there next monday, on the infra hackathon :) [1]
[1] https://docs.google.com/spreadsheets/d/1PGGqI5tT_pmF7HUdg63FlozuVoQOBQaO-VID...
Best, -- Didi _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
participants (5)
-
David Caro
-
Eli Mesika
-
Eyal Edri
-
Sandro Bonazzola
-
Yedidyah Bar David