-
Notifications
You must be signed in to change notification settings - Fork 274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability to cancel specific jobs with trigger scoped cancellation when building current patchset or other options similar to server scope. #415
Conversation
… for current patchset updates
@@ -11,4 +11,6 @@ | |||
files="InjectedTest.java"/> | |||
<suppress checks=".+" | |||
files="[/\\]generated-sources[/\\]"/> | |||
<suppress checks="FileLength" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind refactoring - my plan is to move that parts of that subclass logic to it's own file. Any concerns with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Went ahead and did this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't reviewed everything yet.
@@ -794,7 +798,8 @@ public ListBoxModel doFillVerdictCategoryItems() { | |||
public void notifyBuildEnded(GerritTriggeredEvent event) { | |||
if (event instanceof ChangeBasedEvent) { | |||
IGerritHudsonTriggerConfig serverConfig = getServerConfig(event); | |||
if (serverConfig != null && serverConfig.isGerritBuildCurrentPatchesOnly()) { | |||
if ((serverConfig != null && serverConfig.isGerritBuildCurrentPatchesOnly()) | |||
|| this.getBuildCancellationPolicy().isEnabled()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You check for null
in EventListener
so I guess you need to check for it here as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
/** | ||
* @return the abortNewPatchsets | ||
*/ | ||
public boolean isAbortNewPatchsets() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of a whole bunch of new fields I'd prefer to just have one bean with the setting in. It can be achieved with for example <f:block>
or rather <f:optionalBlock>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will try that out again. My last attempt doing that jelly code ended in tears.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still no success. How would I rewrite the Jelly + java code to make this work?
if (serverConfig != null && serverConfig.isGerritBuildCurrentPatchesOnly()) { | ||
if (t.getBuildCancellationPolicy() != null && t.getBuildCancellationPolicy().isEnabled()) | ||
{ | ||
t.getRunningJobs().cancelTriggeredJob(changeBasedEvent, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be wrong, but it looks strange; since you aren't calling scheduled
here I don't think that it is recorded among the running jobs correctly and so can't be cancelled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll double check - the code to keep it separate from cancelling ALL jobs with the triggered event was a bit more nuanced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if we don't have a serverwide or trigger policy, it doesn't get added.
If the trigger policy is set, we add it here: https://github.com/jenkinsci/gerrit-trigger-plugin/pull/415/files#diff-23a1e696752ef9408f31a5c9aa77c5d3R2408
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was moved when refactored - https://github.com/jenkinsci/gerrit-trigger-plugin/pull/415/files#diff-da694feab949be34e2a85c791e48f0fbR118
@@ -91,6 +91,8 @@ | |||
private SshServer sshd; | |||
private SshdServerMock serverMock; | |||
private GerritServer gerritServer; | |||
private static final int DELAY = 2000; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you had to do this because you got outside of the area for MagicNumber
ignore rule?
You could just increase the number on Line 73.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind moving away from that magical number unless you want it there. Either way I can revert and update the checkstyle or remove it entirely.
…policy Change-Id: I1e654243a9030635062339f3657f71eb1580ee73
Change-Id: I12c65e99c10d8df714e52157fe730fe519e737a1
I think all that's left on this is the Jelly code rewrite - is the anything else you need fixed? |
* Class for maintaining and synchronizing the runningJobs info. | ||
* Association between patches and the jobs that we're running for them. | ||
*/ | ||
public class RunningJobs { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You missed to reformat.
Looks good. |
Change-Id: Ibc27ad7b252ec0762f677a32ce32ab62a1b8958a
Reworking this PR now to fix tests. Should have an update either today or tomorrow. |
And I've probably introduced a merge conflict hell for you today, sorry about that :/ |
No worries - I'm tracking down a regression with RunningJobs being moved out anyways. |
Change-Id: I208713390358c780587fa7c03ecae96ebfa8c197
…plugin into trigger_cancel_current_patchset Change-Id: I0b201c254f758b88b4bd34448d53ae1338f5a734
Pushed new change to branch but this PR isn't updated. May need to poke github to see if there is a sync issue. |
Change-Id: I93543b86a3fbd7c84bb9adb28d5a1b9d9755a2db
@rsandell - Ok ready for review. Lemme know if you want me to rebase/squash commits. |
@rsandell - Not sure what happened on that last check - can it be re-run? |
@MattLud could you change the title to something more descriptive, for the changelog, and add a description please? |
Will do! Expect it later today - Thanks again for reviewing it! |
@MattLud could you maybe provide a specific use case this change addresses? I'd like to understand the rationale and potentially improve on our side by taking advantage of it. |
@romanek-adam Previously, you could only set server-wide setting if a build would be aborted if a new patchet set was published. Since we run multi-tenant jenkins servers with a variety of needs, we needed granularity to control this at the trigger/job level. |
Any reason this change removed my fix for only storing events for the specified gerrit server? Running into the same issues I had before with the latest plugin where we keep replaying events that should not be replayed. 9d95d15#diff-d20ef7cffb03100f9595b376cd9f40692a8b0788597e87830df09fa0f3244a63 |
This PR will add the ability for specific jobs to have running builds aborted upon seeing a new patchset pushed. The options added mirror the server-level triggers that currently exist but are instead scoped to trigger that have the options enabled. This should not impact existing server cancellation.