FYI this breaks the ec2-fleet plugin.

This "fix" busted all my jobs that use SSH slaves - they all get a classNotFoundException on the trilead/ssh2/Base64 class.  I assumed there was some other dependency that this required so I made sure to be on the very latest Jenkins and the very latest of all my plugins.  It still broke everything.  

What do we have to do in order to make this version work?  It's seriously busted.

Can this "fix" be reversed?  It completely breaks all uses of the SSH Slaves plugin.  Any job using this plugin immediately gets a stack trace with a ClassNotFoundException with the trilead ssh2 Base64 class.  This includes being at the very latest release of Jenkins and the latest of all other plugins.  I tried reverting the Jenkins to the previous release but it didn't help.

did someone help to fix it, my jenkins has down for 1 day

I also have the same problem. I have rolled back the SSH slave plug-in to the previous version, waiting for repair.

Using SSH Slaves 1.29.0 to configure the slave page, you can add credentials, but you can't choose. By default, you limit the current and only the current

thank you, yyl1007, jenkins is back!

The rollback work fine. Thanks guys.

I also commented about the issue in the developers google group https://groups.google.com/forum/#!topic/jenkinsci-dev/Ba69w3M-jX0

This is pretty nasty. I am running Jenkins 2.138.3 LTS and updated to SSH Slaves 1.29.0 this morning. Restarting Jenkins resulted in an exception on the entire browser window. Jenkins UI was blocked. Had to rollback the plugin manually from the command line.

if this PR passes the CI I will merge and release a new version without mask the core classes this fix the issue, then I will include the dependency on all plugins that depends on ssh-slaves-plugin, finally, I will mask the dependency on trilead-api plugin

I just upgraded the ssh-slave from 1.28.1 to 1.29.1, and immediately got the same stack-trace.

Downgrading to 1.29.0 also produced the stack-trace.

Finally, back on 1.28.1, everything is back to normal.

On each of the above mentioned versions, I've tested both trilead-api 1.0.0 and 1.0.1 - but this plugin version does not seem to affect the problem.

I have confirmation on a few issues that the upgrade to 1.29.1 fix the issue, it required a restart if not yo do not change the plugin, check that you are using the right version of the plugin by executing the following script in the Jenkins script console

result = ''
for (plugin in Jenkins.instance.pluginManager.plugins) {
	result = result + "${plugin.displayName}" + ',' + "${plugin.version}\n"
}
return result

JENKINS-54061
JENKINS-54713

ifernandezcalvo

I were manually installing the plugins, and stopping the Jenkins service before each installation.

The only two plugins changed on my system were ssh-slave and trilead-api.

I manually tried these combinations (in this order), before I wrote here:

1.29.1 + 1.0.1 = Stacktrace on boot

 1.29.1 + 1.0.0 = Stacktrace on boot

1.29.0 + 1.0.0 = Stacktrace on boot

1.28.1 + 1.0.0 = Works

1.28.1 + 1.0.1 = Works

1.29.0 + 1.0.1 = Stacktrace on boot

Ended up using this combination:

1.28.1 + 1.0.1 = Works

Hi ifernandezcalvo, 

I can confirm fsteff's report, exactly the same issue on CentOS 7, with Jenkins LTS 2.138.3. Only the 1.28.1 works for me. 

regards,

Csaba

ssh-slaves 1.28.1 does not use trilead-api, it was introduced in 1.29.0.

I have tested a few stuff

• A fresh installation of Jenkins 2.152, I do not see the issue
• A fresh installation of Jenkins 2.73.3(I choose this because you can not install 1.29.X), then upgrade to 2.152 and upgrade the plugins, I do not see the issue

You can test the same if you want:

• Copy your JENKINS_HOME and your jenkins.war to a test machine
• Go to the test machine
• Go to the JENKINS_HOME folder
• Remove the plugin from the plugins folder rm -fr plugins/ssh-slaves* (the asterisk matters)
• Start Jenkins 'JENKINS_HOME=$(pwd) java -jar jenkins.war'
• Enter in the test instance on port 8080 'http://test.exampl.com:8080'
• Upgrade the plugin
• Restart