Details
-
Improvement
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Duplicate
-
None
-
any
Description
slave.jar should update itself when Jenkins is updated. I have a large qty of remote build agents, and when we see problems, we never know if the outdated slave.jar is relevant or not. This should be changed once and for all so that it detects the change and auto updates itself when the Jenkins server is updated.
Competing CI servers have had this as basic functionality for years, it would be great if Jenkins supported the same.
Attachments
Issue Links
- duplicates
-
JENKINS-16490 New versions of Remoting should be automatically pushed to Java Web Start agents
-
- Resolved
-
Activity
re: a batch script, is the intended usage for me to launch that from the command line of the build agent(s) at the time that I upgrade the Jenkins master?
This can be done every time you start the slave. I assume it's already a fairly manual process of launching a batch script or similar, when it's not a service, so this can probably be integrated rather easily.
The potentially bad/awkward aspect of not doing this is that (I think) slave.jar can get out of sync to the point where there is a bug – there is no slave<->master compatibility version enforcement that I am aware of, _if _the user doesn't remember to upgrade their slave(s) each time.
The unfortunately named VersionColumn Plugin can help you with that: https://wiki.jenkins-ci.org/display/JENKINS/VersionColumn+Plugin
Actually I'm not entirely sure why Jenkins even allows to use outdated slave.jars. Maybe something needs to be tidied up there, and then an auto-update mechanism would make a lot more sense, as there's absolutely no need for older slave.jars to be around.
Ryan Campbell
added a comment - oleg_nenashev, this seems to be a duplicate of JENKINS-39237. Should it be closed as such?
Ryan Campbell
added a comment - oleg_nenashev , this seems to be a duplicate of JENKINS-39237 . Should it be closed as such? recampbell It's not a duplicate. JENKINS-39237 is only about Windows services. This one is about any agent (self-update in remoting.jar)
Hi,
re: a batch script, is the intended usage for me to launch that from the command line of the build agent(s) at the time that I upgrade the Jenkins master? If so, I would agree that it's slightly more convenient than me pointing a web browser to the master and clicking slave.jar with the intent of saving it locally and then killing/re-running (when I remember to do so).
The point of logging this issue isn't that there is no path forward to proceed – it's certainly not a high priority 'bug', I'm sure we're all in agreement. And today, everyone can update their slave.jar file manually (or create a script like the one you proposed), so nobody is 'stuck'. But there are so many aspects of Jenkins that are slick and provide a good user experience, why shouldn't this be one of them?
The potentially bad/awkward aspect of not doing this is that (I think) slave.jar can get out of sync to the point where there is a bug – there is no slave<->master compatibility version enforcement that I am aware of, _if _the user doesn't remember to upgrade their slave(s) each time. I know there have been multiple Jenkins users that have had that question and the same feeling of (hmm, is the current problem I'm seeing with this slave due to the fact that I didn't upgrade the slave.jar when I upgraded the master, even though slave.jar rarely changes?)
Anyway, that's the scoop behind me logging this. The benefit (to me) seems clear, even though we'd probably both be in violent agreement that it's not a P0...