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-45471] - Generalize handling of scheduling errors and prevent NPEs in perform3() #115

Merged
merged 2 commits into from Jul 12, 2017

Conversation

oleg-nenashev
Copy link
Member

The change polishes #114 and adds check of another NPE risk in BuildTriggerConfig#perform3(). Will add tests later... really...

https://issues.jenkins-ci.org/browse/JENKINS-45471

@reviewbybees @fbelzunc

@ghost
Copy link

ghost commented Jul 12, 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.

listener.error("Skipping " + jobToTrigger.getFullName() + "...");
if (LOGGER.isLoggable(Level.CONFIG)) {
String message = String.format("Cannot schedule project %s. Job type is not parameterized, "
+ "or there is no Item/Build permission for the current authentication %s. "
Copy link
Member

Choose a reason for hiding this comment

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

As I have mentioned previously, Item/Build is nonexistent. The Java constant is Item.BUILD. The permission as displayed in the UI is Job/Build.

+ "or there is no Item/Build permission for the current authentication %s. "
+ "Skipping...", jobToTrigger, Jenkins.getAuthentication().getName());
LOGGER.log(Level.CONFIG, String.format("%s: %s", run, message),
new UnsupportedOperationException("Cannot schedule job " + jobToTrigger.getFullName()));
Copy link
Member

Choose a reason for hiding this comment

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

Is a stack trace really necessary here? I do not see why.

private void reportSchedulingError(@Nonnull Run<?, ?> run, @Nonnull Job<?, ?> jobToTrigger, @Nonnull BuildListener listener) {
// Do not print details to Build Listener, they have been reported previously in #canTriggerProject()
listener.error("Skipping " + jobToTrigger.getFullName() + "...");
if (LOGGER.isLoggable(Level.CONFIG)) {
Copy link
Member

Choose a reason for hiding this comment

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

BuildTrigger and ReverseBuildTrigger print similar messages at WARNING. Is there a reason you are suppressing this message from logs by default? It is unlikely an admin will ever see it—by the time they figure out they need to be turning on this logger, they will already know about the problem and the fix. The point is to guide admins to help their users address configuration problems.

Copy link
Member Author

Choose a reason for hiding this comment

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

@jglick ADMIN already gets a WARNING here: https://github.com/jenkinsci/parameterized-trigger-plugin/blob/master/src/main/java/hudson/plugins/parameterizedtrigger/BuildTriggerConfig.java#L571-L582

This logging with Exception exists for extra diagnostics purpose only

Copy link
Member

Choose a reason for hiding this comment

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

OK…confusing but it sounds like this is just for debugging?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep. Will add more comments during the logging update in the plugin

@oleg-nenashev oleg-nenashev merged commit 2c7e3c1 into jenkinsci:master Jul 12, 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
3 participants