-
Notifications
You must be signed in to change notification settings - Fork 720
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
[JENKINS-24141] Switch to using RunWithSCM for getCulprits logic #155
Conversation
Set CI to build with JDK 8. |
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.
AFAICT there is no added test coverage for WorkflowRun.getCulprits
, or did I just miss it?
@@ -39,6 +39,7 @@ public void send(final String format, final Object... args) { | |||
} | |||
} | |||
final Debug debug = new Debug(); | |||
|
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.
gratuitous, revert
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.
...dangit. =)
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.
While I am happy with these changes If they require features not in the latest LTS Im hesitant to merge until they are as then any other changes won't be available to LTS users (such as my work)
Even assuming the upstream PR does get merged and released in a weekly, there is no expectation this PR would get merged in the near future. Probably you would want to wait until the API makes it into an LTS release, at least. |
@jglick See https://github.com/jenkinsci/email-ext-plugin/pull/155/files#diff-14528565ae064617b0382642b3e14276 - there was previously special-casing for non- |
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 see.
This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation. |
pom.xml
Outdated
<workflow-step-api.version>2.9</workflow-step-api.version> | ||
<workflow-aggregator.version>2.5</workflow-aggregator.version> | ||
<workflow-job.version>2.12</workflow-job.version> | ||
<jenkins.version>2.60</jenkins.version> |
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.
Needs sign-off from the plugin maintainer
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.
Reflection could help to temporary avoid bumping Jenkins core dependency, but I am not a big fan of that either. There are some unrelated updates && missing direct tests for Pipeline, but it is up to the plugin maintainer (as well as the core bump)
🐝 and @reviewbybees done, formally the PR is correct
Yes, that is definitely an option here, since it is a single method call so the whole idiom would be only a few lines (incl. a comment reminding the maintainer to switch to a direct call when updating the baseline). Would get this in the hands of (2.60+) users sooner, assuming the maintainer is reluctant to use a new baseline, so it might be a reasonable tradeoff. |
So the reflection thing gets a bit hairier due to there already being a |
Set<User> users = ((AbstractBuild<?,?>)run).getCulprits(); | ||
RecipientProviderUtilities.addUsers(users, context, env, to, cc, bcc, debug); | ||
} else { | ||
// TODO: core 2.60+, workflow-job 2.12+: Switch to checking if run is RunWithSCM and make catch an else block |
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.
…or simply delete the else
block.
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.
Yeah, I guess we can probably just rule out any other weirdo job types out there.
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.
Actually, I like what I've got here. It's a nice better-safe-than-sorry fallback.
@@ -37,6 +37,7 @@ | |||
import hudson.scm.ChangeLogSet; | |||
import hudson.tasks.MailSender; | |||
|
|||
import javax.mail.MethodNotSupportedException; |
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.
Huh?
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.
Whoops..
@@ -74,6 +76,7 @@ private RecipientProviderUtilities() { | |||
addChangeSetUsers(changeLogSet, users, debug); | |||
} | |||
} else { | |||
// TODO: core 2.60+, workflow-job 2.12+: Decide whether to remove this logic since it won't be needed for Pipelines any 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.
Right, in 2.60+ we can just drop the else
clause.
PowerMockito.when(build5.getResult()).thenReturn(Result.FAILURE); | ||
final FreeStyleBuild build5 = PowerMockito.spy(new FreeStyleBuild(p)); | ||
PowerMockito.doReturn(Result.FAILURE).when(build5).getResult(); | ||
PowerMockito.doReturn(build4).when(build5).getPreviousCompletedBuild(); |
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.
This is one reason I loathe mocking tests—they have to be rewritten even if you make compatible changes.
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.
Ahyup.
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.
🐝
<jenkins.version>2.0</jenkins.version> | ||
<workflow-api.version>2.11</workflow-api.version> | ||
<workflow-cps.version>2.29</workflow-cps.version> | ||
<workflow-durable-task-step.version>2.11</workflow-durable-task-step.version> |
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.
make sure that all deps are compatible with Jenkins 2.0after the dep downgrade
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.
They are - none of the core Pipeline plugins have dependencies on core >=2.0 until workflow-job
2.12.
} | ||
} | ||
} catch (NoSuchMethodException | InvocationTargetException | IllegalAccessException e) { | ||
debug.send("Exception getting culprits for %s: %s", run, e); |
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.
🐜 this is a valid behavior for 2.60-, no? Maybe it needs more graceful message, but up to you
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.
Good point.
Test failures which look real. |
JENKINS-24141
Downstream of jenkinsci/jenkins#2730 and jenkinsci/workflow-job-plugin#35
cc @reviewbybees