-
-
Notifications
You must be signed in to change notification settings - Fork 275
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-34819] Allow disabling the protocols individually #83
Conversation
- Also ensure that a fatal unexpected error in one protocol does not prevent a fall-back
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. |
} catch (RuntimeException e) { | ||
events.status("Protocol " + protocol.getName() + " encountered a runtime error", e); | ||
} catch (Error e) { | ||
events.status("Protocol " + protocol.getName() + " could not be completed due to an error", 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.
Uhm. Do we really want to continue after it? Errors are commonly fatal
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.
IOError is one that we should continue after and I fear could be one that gets thrown
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.
feel free to update this PR to whatever you want, but if JnlpProtocol3 throws an Error, e.g. LinkerError, etc we should still try the others
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 it's acceptable. If the error is not handleable, it will just blow up in another place
Yay, remoting build failed due to the remoting bug.
|
🐝 |
Created a separate issue for it: https://issues.jenkins-ci.org/browse/JENKINS-34819 |
…oting to 2.59 Changes: 2.58: * [JENKINS-34213](https://issues.jenkins-ci.org/browse/JENKINS-34213) - Ensure that the unexporter cleans up whatever it can each sweep (jenkinsci/remoting#81) * [JENKINS-19445](https://issues.jenkins-ci.org/browse/JENKINS-19445) Force class load on UserRequest in order to prevent deadlock on windows nodes when using JNA and Subversion (jenkinsci/remoting#82) * [JENKINS-34808](https://issues.jenkins-ci.org/browse/JENKINS-34808) - Allow user to adjust socket timeout (jenkinsci/remoting#68) 2.59: * [JENKINS-34819](https://issues.jenkins-ci.org/browse/JENKINS-34819) - Allow disabling the remoting protocols individually. Works around issues like [JENKINS-34121](https://issues.jenkins-ci.org/browse/JENKINS-34121) (jenkinsci/remoting#83)
@reviewbybees