Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-23880

JNLP slave : slave.jar should update itself when Jenkins is updated

    • Icon: Improvement Improvement
    • Resolution: Duplicate
    • Icon: Minor Minor
    • core, remoting
    • None
    • any

      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.

          [JENKINS-23880] JNLP slave : slave.jar should update itself when Jenkins is updated

          If you use "Let Jenkins Control this Windows Slave as Windows service" as the launch method, this is what happens.

          Vincent Latombe added a comment - If you use "Let Jenkins Control this Windows Slave as Windows service" as the launch method, this is what happens.

          boris ivan added a comment -

          Thanks for the workaround, but running as a service isn't an option for me. Windows has some very strict security regarding having 'services' writing to mapped drives (Z:, etc), even if you run that service under specific credentials. So, I need to launch the build agent from the command line, which Jenkins supports.

          I need the slave.jar to upgrade when Jenkins upgrades, in that scenario as well. Jenkins competitors do this successfully, also when launched from the command line (teamcity, etc)

          boris ivan added a comment - Thanks for the workaround, but running as a service isn't an option for me. Windows has some very strict security regarding having 'services' writing to mapped drives (Z:, etc), even if you run that service under specific credentials. So, I need to launch the build agent from the command line, which Jenkins supports. I need the slave.jar to upgrade when Jenkins upgrades, in that scenario as well. Jenkins competitors do this successfully, also when launched from the command line (teamcity, etc)

          Daniel Beck added a comment -

          So, I need to launch the build agent from the command line

          Is a batch file that basically does

          wget http://jenkins/jnlpJars/slave.jar
          java -jar slave.jar …

          out of the question?

          (http://gnuwin32.sourceforge.net/packages/wget.htm)

          Daniel Beck added a comment - So, I need to launch the build agent from the command line Is a batch file that basically does wget http: //jenkins/jnlpJars/slave.jar java -jar slave.jar … out of the question? ( http://gnuwin32.sourceforge.net/packages/wget.htm )

          re-tagging this issue properly.

          Vincent Latombe added a comment - re-tagging this issue properly.

          boris ivan added a comment -

          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...

          boris ivan added a comment - 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...

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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?

          Oleg Nenashev added a comment -

          recampbell It's not a duplicate. JENKINS-39237 is only about Windows services. This one is about any agent (self-update in remoting.jar)

          Oleg Nenashev added a comment - recampbell It's not a duplicate. JENKINS-39237 is only about Windows services. This one is about any agent (self-update in remoting.jar)

          Oleg Nenashev added a comment -

          OTIH it is a duplicate of JENKINS-16490

          Oleg Nenashev added a comment - OTIH it is a duplicate of JENKINS-16490

            Unassigned Unassigned
            borisivan boris ivan
            Votes:
            2 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: