Skip to content
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

Merged
merged 9 commits into from
Oct 23, 2017

Conversation

abayer
Copy link
Member

@abayer abayer commented May 4, 2017

@jglick
Copy link
Member

jglick commented May 5, 2017

Set CI to build with JDK 8.

@jglick jglick closed this May 5, 2017
@jglick jglick reopened this May 5, 2017
Copy link
Member

@jglick jglick left a 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();

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gratuitous, revert

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...dangit. =)

@davidvanlaatum davidvanlaatum self-assigned this May 6, 2017
@davidvanlaatum davidvanlaatum self-requested a review May 6, 2017 03:05
Copy link
Contributor

@davidvanlaatum davidvanlaatum left a 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)

@jglick
Copy link
Member

jglick commented May 6, 2017

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.

@abayer
Copy link
Member Author

abayer commented May 8, 2017

@jglick See https://github.com/jenkinsci/email-ext-plugin/pull/155/files#diff-14528565ae064617b0382642b3e14276 - there was previously special-casing for non-AbstractBuilds, which was tested in CulpritsRecipientProviderTest, so we just have to make sure the tests keep passing rather than write new ones.

Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see.

@ghost
Copy link

ghost commented May 18, 2017

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>
Copy link
Member

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

Copy link
Member

@oleg-nenashev oleg-nenashev left a 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

@jglick
Copy link
Member

jglick commented May 19, 2017

Reflection could help to temporary avoid bumping Jenkins core dependency

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.

@abayer
Copy link
Member Author

abayer commented May 19, 2017

So the reflection thing gets a bit hairier due to there already being a getChangeSets on AbstractBuild pre-2.60, but it's @Restricted(DoNotUse.class). So basically I'll revert to the previous behavior there.

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
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

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;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh?

Copy link
Member Author

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.
Copy link
Member

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();
Copy link
Member

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahyup.

Copy link
Member

@oleg-nenashev oleg-nenashev left a 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>
Copy link
Member

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

Copy link
Member Author

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);
Copy link
Member

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point.

@jglick
Copy link
Member

jglick commented Jun 16, 2017

Test failures which look real.

@abayer abayer merged commit dfb6bbb into jenkinsci:master Oct 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants