On 18/09/15 01:19, Daniel Beck wrote:
On 17.09.2015, at 17:04, Thorsten Möllers <[email protected]> wrote:
- I doubt you really need the RunData, why not query all running jobs for what
their (upstream) causes are when you get notified about a run abort? Not sure
what's saved/loaded in the Plugin class, but I expect the current design with the
static > HashMap doesn't handle a Jenkins restart well (the queue is
persisted and restored on restart).
Because it is not only supposed to kill upstream. If I kill the upstream build,
I want to kill other downstream builds as well. Problem is I couldn't find a a
way to get a list of all downstream builds for a running build.
Therefore I collect this information at runtime.
Right. That's why I wrote you'd need to look at all running builds' causes to determine
whether they are downstream from the "reference build". I think that should
work and allow you to do this without RunData.
I don't think this is an option. We have a huge set of running jobs, a
lot of them short lived, so I try to keep the cost for a single job
exiting minimal. As I see it, currently the memory allocated in my
plugin for a single build is O(1), since the hierarchy structure is more
or less static. The execution time to handle a single notification is
also O(1), for the same reason. Going through all builds would add an
operation O(n), n being the number of currently running builds, which is
quite huge in our system. Since a lot of our builds are short-lived,
this task would be executed quite frequently.
.
Also the log info in the console output is invaluable for us, to see the
full chain of jobs being killed leading to the most upstream one being
killed. This data is collected in RunData.reason.
BTW, it looks like you don't look at queue items. If a build is still in the
queue when you abort whatever is upstream from it, it'll not be canceled.
This would be a good improvement for the next version. But from what I
see, Jenkins does not provide notifications for triggered builds, just
for started ones. Where do I get a list of queued builds?
Jenkins restart: I have to make sure that no persistent data is stored.
If you have no persistent data, and the queue gets restored on restart, how can
your plugin behave correctly afterwards?
Jenkins restart would be the exception. Usually, Jenkins runs for weeks
in our setup without a restart, and when it restarts, it is usually a
scheduled maintenance break where no jobs are active anyway. In the rare
case of an unexpected Jenkins restart I could live with some builds
being continued instead of aborted, it would be the least of our problems.
A non-library plugin without any UI is not a great idea as admins may easily
forget it exists, and users don't even know it's there.
I agree, you have a point there. Not sure how to align with my previous comment
though.
Maybe provide both static checkboxes in job config for all the options, and
treat them like env-vars, giving users the option to use one or the other?
Makes checking whether an option is set a bit more effort, but you have the
option to do both full UI (static) config, and allow the alternative of
per-build configuration through env vars.
I will look into it, but not for a first release probably.
For the naming: How about "BuildHierarchyKiller"? I think that would be
unambiguous...
Br,
Thorsten
--
You received this message because you are subscribed to the Google Groups "Jenkins
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/55FBA708.8050705%40thorzten.de.
For more options, visit https://groups.google.com/d/optout.
