Date: prev next · Thread: first prev next last
2015 Archives by date, by thread · List index


On Thu, Nov 19, 2015 at 2:23 AM, David Ostrovsky <d.ostrovsky@gmx.de> wrote:

On Wed, Nov 18, 2015 at 19:20:03 PST, Ashod Nakashian <ashnakash at
gmail.com> wrote:

Sorry, I didn't explain well.

The patches are related. They are updates based on feedback, partial
failure or improvement.

[...]

Why do people send multiple patches per push? That's the right question
to ask.

And the answer is: to improve the previous patch.

Hence my question. If a patch has partially failed, or I got feedback
to
improve it, or (insert reason here), and I want to push an update, why
should the previous patch still build when it's not necessary?

Hope this makes sense.

Yes, indeed. LibreOffice is using Jenkins CI and Gerrit trigger plugin
for integration between Jenkins and Gerrit. This plugin provides the
feature you are asking for: job cancellation when patch set became
obsolete because of uploading new patch during the old patch set is
still building. Moreover, when patch_set_42 is building, and you've
uploaded another 10 patch sets simultaneously, so that for every patch
set i, 1 <= i <= 10, the build for patch_set_42 + i wouldn't be even
started, but only the build for patch_set_53. Unfortunately for some
reasons this feature wasn't activated yet. See also the announcement
on the trigger site: [1].

"
EXPERIMENTAL: Cancel old running jobs when a new Patch Set is uploaded
on the same change.
This feature is set as experimental due to problems we've found during
testing.
You can enable the feature from the Manage Jenkins/Gerrit Trigger page.
All help in debugging the problems we've found is appreciated, that's
why it is in this release.
"

So yes, I agree that this feature should be activated on our infra. To
do that, we would need to investigate, track down and fix the problems.
To be able to do so, we need staging Jenkins and Gerrit instances, where
we could reproduce and troubleshoot this and other issues, like simulate
Gerrit upgrade to newer version, etc.


Thanks David. This is exactly the answer I was looking for.



Unfortunately, it cannot be done, because our infra team doesn't have
free resources to set up new VM and install Gerrit and Jenkins on them.
Last time i asked why they don't have resources and the answer was: this
project is not OpenStack that is spending substantial resources for
their infrastructure. No wonder that my request to set up staging Gerrit
instance is pending for years now: [2]. So I wouldn't expect that
staging Jenkins instance would be available in 5-10 years (if at all),
if you would request it today on infra issue tracker.

IOW, just accept that all patch sets are get built. Well, at least you
have asked and now you know the answer why it is how it is.

[1] https://wiki.jenkins-ci.org/pages/viewpage.action?pageId=63931391
[2] https://redmine.documentfoundation.org/issues/1147


Not great. I'm hoping this could still be tackled, especially when the
benefits are more than the case at hand (as you mentioned staging is a
major advantage).

I'm still hopeful this is doable. Perhaps it could be suggested for
consideration in next year's budget?

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.