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

New versions of Remoting should be automatically pushed to Java Web Start agents

      As described in JENKINS-9679, merely updating the version of slave.jar served from Jenkins master does not cause JNLP agents to use the new version; they persist in using the JNLP cache. This makes debugging changes difficult, and can result in bug fixes seeming to not take effect in user deployments.

      We do set an immediate Expires header on /jnlpJars/slave.jar but apparently this does not suffice.

          [JENKINS-16490] New versions of Remoting should be automatically pushed to Java Web Start agents

          Jesse Glick added a comment -

          Ah, how about that!

          Jesse Glick added a comment - Ah, how about that!

          Oleg Nenashev added a comment -

          I also think that Jenkins should have an extension point, which allows to provide custom slave.jar version to users.

          Use-cases:

          • Apply a patch for client-side without the master's restart
          • Use custom builds with modified default values, etc. (our users don't like following internal guides)

          Oleg Nenashev added a comment - I also think that Jenkins should have an extension point, which allows to provide custom slave.jar version to users. Use-cases: Apply a patch for client-side without the master's restart Use custom builds with modified default values, etc. (our users don't like following internal guides)

          I remember reading in another thread that jenkins-slave.exe is updated automatically, couldn't it take care of updating the slave.jar too?

          Another idea: would a redirect of the /jnlpJars/slave.jar to /jnlpJars/slave-vx.xxx.x.jar help?

          Last time the slave.jar had to be updated i had to learn powershell and write a script that deployed the new slave.jar across all our windows slaves - that was frustrating and took way too long for something that ought to be built in.

          Ing. Christoph Obexer added a comment - I remember reading in another thread that jenkins-slave.exe is updated automatically, couldn't it take care of updating the slave.jar too? Another idea: would a redirect of the /jnlpJars/slave.jar to /jnlpJars/slave-vx.xxx.x.jar help? Last time the slave.jar had to be updated i had to learn powershell and write a script that deployed the new slave.jar across all our windows slaves - that was frustrating and took way too long for something that ought to be built in.

          Jorg Heymans added a comment -

          Arriving here after installing Version Column Plugin because it was featured in Plugin Spotlight on the jenkins homepage. After jenkins restart all our windows nodes were marked offline because of outdated slave.jar, fun times clicking on all of them to mark them back online Anyone found a way to force an update on JNLP slaves somehow ?

          Jorg Heymans added a comment - Arriving here after installing Version Column Plugin because it was featured in Plugin Spotlight on the jenkins homepage. After jenkins restart all our windows nodes were marked offline because of outdated slave.jar, fun times clicking on all of them to mark them back online Anyone found a way to force an update on JNLP slaves somehow ?

          Oleg Nenashev added a comment -

          heymjo, are you using Windows service on Windows? If yes, I'm working on such feature for WinSW

          Oleg Nenashev added a comment - heymjo , are you using Windows service on Windows? If yes, I'm working on such feature for WinSW

          Jorg Heymans added a comment -

          Yes we are using windows service.

          Jorg Heymans added a comment - Yes we are using windows service.

          Oleg Nenashev added a comment -

          Created JENKINS-39237 as a follow-up for Windows slaves. I hope to deliver it shortly

          Oleg Nenashev added a comment - Created JENKINS-39237 as a follow-up for Windows slaves. I hope to deliver it shortly

          Oleg Nenashev added a comment -

          The feature for Windows service agents has been delivered in Jenkins 2.50.
          Regarding the pure agents, it is still TODO

          Oleg Nenashev added a comment - The feature for Windows service agents has been delivered in Jenkins 2.50. Regarding the pure agents, it is still TODO

          Oleg Nenashev added a comment -

          WinSW changes are not the LTS candidate. Whatever needs to be done for other agent types, it won't be an LTS candidate as well. And this issue is actually not a bug anyway. It's architecture flaw, but still an improvement/new feature

          Oleg Nenashev added a comment - WinSW changes are not the LTS candidate. Whatever needs to be done for other agent types, it won't be an LTS candidate as well. And this issue is actually not a bug anyway. It's architecture flaw, but still an improvement/new feature

          Jesse Glick added a comment -

          With the removal of Java Web Start (JENKINS-51820) there is nothing more to do here: particular agent service systems have their own ways of selecting a Remoting version.

          Jesse Glick added a comment - With the removal of Java Web Start ( JENKINS-51820 ) there is nothing more to do here: particular agent service systems have their own ways of selecting a Remoting version.

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            16 Vote for this issue
            Watchers:
            23 Start watching this issue

              Created:
              Updated:
              Resolved: