-
Bug
-
Resolution: Duplicate
-
Major
-
None
-
Platform: All, OS: All
Today, i dont see the Hudson Version of any Hudson Slave.
Please provide this kind of view in the hodson nodes overview table.
- duplicates
-
JENKINS-453 Check version mismatch of slave and master
-
- Resolved
-
- is duplicated by
-
-
- Closed
-
[JENKINS-4066] Display nodes Hudson Version
azgard
added a comment - Yes, the slave.jar version.
In our environment we run hudson on windows machines per windows service.
If i update my master hudson i dont know if the slaves also updated or i rerun
install as service.
azgard
added a comment - Yes, the slave.jar version.
In our environment we run hudson on windows machines per windows service.
If i update my master hudson i dont know if the slaves also updated or i rerun
install as service. 
mdonohue
added a comment - slave.jar rarely ever changes. The code that runs on the slaves is downloaded
from the master instance of Hudson, so there is never version skew.
mdonohue
added a comment - slave.jar rarely ever changes. The code that runs on the slaves is downloaded
from the master instance of Hudson, so there is never version skew. 
huybrechts
added a comment - Not all deployment scenarios involve automatic updating of the slave, and this
is something that has caused troubles in the past.
huybrechts
added a comment - Not all deployment scenarios involve automatic updating of the slave, and this
is something that has caused troubles in the past. mdonohue
added a comment - yes, but if slave.jar won't start due to incompatibility, there's no reasonable
way to get the version information to the master. So the UI will only ever show
working configurations - it won't be useful to diagnose failures.
mdonohue
added a comment - yes, but if slave.jar won't start due to incompatibility, there's no reasonable
way to get the version information to the master. So the UI will only ever show
working configurations - it won't be useful to diagnose failures. version could be cached from last time it was connected ok? presumably all your
slaves worked before you upgrade hudson itself, so this is likely to be accurate
(though it could be marked as "last known")..
mdonohue
added a comment - Also, I suspect the reporter of this issue thinks that a slave could run Hudson
1.299 while the master is running 1.320. That is what I meant when i said the
'code that runs on the slaves is downloaded from the master instance of Hudson'
I was not referring to the auto-download of slave.jar.
Keeping track of the last working version of slave.jar might be useful though.
mdonohue
added a comment - Also, I suspect the reporter of this issue thinks that a slave could run Hudson
1.299 while the master is running 1.320. That is what I meant when i said the
'code that runs on the slaves is downloaded from the master instance of Hudson'
I was not referring to the auto-download of slave.jar.
Keeping track of the last working version of slave.jar might be useful though. I made a start in this direction.. so far it just reports the version# in the
slave log when the slave is launched.. is this helpful?
r23750 | mindless | 2009-11-15 21:21:31 -0800 (Sun, 15 Nov 2009) | 2 lines
Changed paths:
M /trunk/hudson/main/core/src/main/java/hudson/slaves/SlaveComputer.java
M /trunk/hudson/main/remoting/pom.xml
M /trunk/hudson/main/remoting/src/main/java/hudson/remoting/Launcher.java
JENKINS-4066 Add version# is slave.jar and report this in log when a node is
launched.
Code changed in hudson
User: : mindless
Path:
trunk/hudson/main/core/src/main/java/hudson/slaves/SlaveComputer.java
trunk/hudson/main/remoting/pom.xml
trunk/hudson/main/remoting/src/main/java/hudson/remoting/Launcher.java
http://fisheye4.cenqua.com/changelog/hudson/?cs=23750
Log:
JENKINS-4066 Add version# is slave.jar and report this in log when a node is launched.
Closing as dup of older issue on this topic, please track #453.
-
-
- This issue has been marked as a duplicate of 453 ***
-
Do you mean the version of slave.jar?