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.
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.
> 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?
>
>> 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.
>
>> - While I understand that Parameterized Trigger allows having an upstream
>> project that still runs, I wonder doubt it's always only one, which seems to
>> be the assumption in your code. While that feature may not consider quiet
>> periods, the node may be missing, so two identically parameterized builds
>> could be collapsed in the queue while waiting for the node to free up.
> Isn't this something only the Workflow plugin does? I saw it with workflow,
> but never with Parameterized Trigger. If this is really an issue for normal
> builds as well, I will replace iUpstream also with a list (vector).
- You have the build step provided by Parameterized Trigger that triggers a
build which the current build is still running.
- A build waits in the queue until a required node ("Restrict where this can
run") becomes available.
- Two queue items with identical parameters are collapsed into one and their
causes merged.
I think it should be fairly straightforward to test this.
--
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/D7FFD881-8B99-49CB-9DA6-E2BFD3E9E58F%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.
