-
-
Notifications
You must be signed in to change notification settings - Fork 8.8k
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
Removing code to support the Remoting-based CLI #3838
Conversation
@mikecirioli as disturbed can you check our internal CLI for any issues with this? |
…roblem was concealed by the original code not checking the command exit code.
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.
It looks good to me. As I said over on the mailing list I'm in favor of removing this deprecated, problematic capability.
I've looked over the changes and they make sense but I haven't done a full in-depth analysis of each change. The build passes locally and on CI so that's a good indicator.
The latest test failure appears to be due to broken UC JSON. |
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.
🐝 Seems a good idea!
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 am -1 w.r.t this change, see the developer mailing list. Other maintainers are welcome to ignore my -1 and merge the pull request taking votes
For reference, Oleg's email on the ML is https://groups.google.com/forum/#!msg/jenkinsci-dev/upgi9c5u63o/W6UmnDwUDwAJ Copying my answer here, because it applies to this PR context well too: I understand your point Oleg, but I feel quite strongly that we shouldn't keep the new test-jdk8 module empty or so for a "just in case" reason.
|
"in the meantime, it would be deeply misleading for everyone, and mainly
newcomers that there is an empty maven module in the source tree." .
Jesse's PR removes not only the Java8-only test module, but the entire
structure which enables creating Java-version-specific tests. Reverting
will be difficult, because Jesse didn't split changes into separate
commits. And there will be likely merge conflicts anyway. This is the
reason why I am -1.
Again, I do not block anybody by my -1. If there is strong consensus
between other contributors, go for it
…On Fri, Feb 1, 2019 at 3:52 PM Baptiste Mathus ***@***.***> wrote:
For reference, Oleg's email on the ML is
https://groups.google.com/forum/#!msg/jenkinsci-dev/upgi9c5u63o/W6UmnDwUDwAJ
Copying my answer here, because it applies to this PR context well too:
------------------------------
I understand your point Oleg, but I feel quite strongly that we shouldn't
keep the new test-jdk8 module empty or so for a "just in case" reason.
1. In case we ever need it again, we can very easily then revert the
removal using Git, and reintroduce this module when needed.
2. in the meantime, it would be deeply misleading for everyone, and
mainly newcomers that there is an empty maven module in the source tree.
------------------------------
—
You are receiving this because you are on a team that was mentioned.
Reply to this email directly, view it on GitHub
<#3838 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AC3IoO92mWKIpTQa53nUIRbWkfJ5FJANks5vJFTGgaJpZM4Z2ub2>
.
|
It seemed like a fairly straightforward change in either direction: moving a couple of POMs around and adding a
Right, I could split off the |
IIUC this is great: we have a path forward don't we? Maybe we could simply:
WDYT? |
I would. It just needs to be highlighted in the changelog, because there are still users out there.
I am fine with it either. If @jglick is concerned about the empty module, I am happy to provide another Java 8-only test case |
You mean, find a retroactive justification? Anyway, sounds like we have a way of making progress, so I can amend this accordingly, and #3872 can adapt.
Absolutely! I included proposed text in the PR description, but I would presume that whoever does the weekly changelog editing would want to boldface parts of this or something. |
…t working there for some reason).
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 took a look through it again. It still looks good. This is a valuable cleanup.
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.
LGTM. Assuming it is properly communicated.
@jglick would you be up to write a short blogpost announcing the removal of the functionality and the CLI commands? I doubt we can offer mitigation for that, but it may be possible to offer somebody some hints to revive the functionality as a standalone plugin if they are ready to invest time into it
@daniel-beck As a Security Officer, are you fine with removing Class deserialization tests? |
Yes this makes sense, let me think about it.
I doubt that is feasible, much less desirable, and would not offer any hope of it. |
Though now we have Incrementals, it might even be simpler to use https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.164-rc27949.9c80cf12deb0/jenkins-war-2.164-rc27949.9c80cf12deb0.war |
Taking the agreements above, it is no longer blocked |
The test failures were due to an update center outage, but I will start a new build just to be sure. |
🎉 |
This stub accodomates the removal of the Remoting CLI in jenkinsci/jenkins#3838 The change does two things: * reintroduce the symbol by providing an no-op object for it * have some code to rewrite the JCasC yaml files without this option
…er parsing CLICommand arguments.
* Playing with WebSocket connections. * Pluggable handlers. * errorWithoutStack * Server-side keepalive pings. * Redesigned to work as an HttpResponse. * Unused dep. * Comment on JnlpSlaveRestarterInstaller. * Sketch of WebSocket-based endpoint for JNLPLauncher. * Comment. * Test enhancement. * Making it more obvious from JNLPLauncherTest where remoting.jar is being loaded from. * Reworked protocol to negotiate remote capabilities. * Unhelpful comment. * Simplifying handshake to use HTTP headers. * Moving code into top-level classes and otherwise prettifying. * Linking to upstream PRs. * Timestamped snapshot + incremental. * Picking up incrementalified build of winstone. * Working around jenkinsci/lib-access-modifier#17. * Finally have an incrementalified build of remoting. * Use -webSocket option. * Handling some close and error methods. * Sending X-Remoting-Minimum-Version. * If hudson.remoting.jnlp.Main._main fails, show the error. * Comment. * GUI analogue of jenkinsci/remoting@86cea5b. * Missing since tags. * Capitalization. * WebSockets.isSupported * Rather than hiding JNLPLauncher.DescriptorImpl when the TCP port is disabled, always display it, but show form validation appropriate to WebSocket or TCP mode. * Form validation fixes. * Minor test improvements. * Reworked WebSocketAgents to be compatible with JnlpAgentReceiver. * Removing WebSocketSession.keepAlive in favor of a global setting applicable to all services. * Add a -webSocket option to the Jenkins CLI. * Using a snapshot deployment of Remoting, pending INFRA-2379. * After #3838 there is no reason to recheck authentication after parsing CLICommand arguments. * Advertise the -webSocket option. * Adapt to newer HtmlUnit. * HtmlUnit/htmlunit#29 seems to have been incompatible. WebClient.addRequestHeader will no longer override a header in a WebRequest, such as when the same WebClient/WebRequest was previously used with different headers. * Tracked down a behavioral change in passing through URL-encoded path characters. HtmlUnit/htmlunit@2c49568 picks up apache/httpcomponents-client@8c04c6a which is the actual change. * Disabled TCP port does not matter in WebSocket mode. * Shade dependencies needed for jenkins-cli.jar. * Help text edit. * jenkinsci/winstone#79 was released as 5.5. * jenkinsci/jenkins-test-harness#183 released as 2.59. * #4387 (comment) * Bumping remoting to a new deployed snapshot. * Need jenkinsci/winstone#86. * jenkinsci/winstone#86 released as 5.6. * Introduced constant for X-Remoting-Minimum-Version. * s/slave/agent/ in GUI * Removing in-JVM test, as it was no longer useful after introducing shading anyway. * Bump. * No need to check for anonymous CONNECT here. * s/jenkins.slaves/jenkins.agents/g for new code. * Restrict the diagnostic endpoint to administrators. * Fixed Javadoc import after package move. * jenkinsci/remoting#357 released as 4.0.
As proposed here. Follows up #2795 by removing the code which that change deprecated. Also
reverts the JDK-8-specific test module introduced in #3759, as these tests are no longer neededleaves the JDK 8 test module but deletes all the ysoserial tests from it.If accepted, these docs would need some updates as well.
@jenkinsci/code-reviewers
Proposed changelog entries
-remoting
option to the Jenkins CLI has been removed. Commands and command options which required this mode have been removed from Jenkins core and will no longer work in plugins; thelogin
,logout
,install-tool
,set-build-parameter
, andset-build-result
commands have been removed. The-p
and--username
/--password
options are also removed. Somepublic
classes and methods which were already deprecated as specific to Remoting mode have been removed, though those likely to be used by plugins have been retained for compatibility.