SSH agent tests failing on default branch

[basil]

The following tests are failing with a TimeoutException while manipulating credentials in SshSlaveLauncher:

• AntPluginTest#locallyInstalledAnt
• AntPluginTest#testAdvancedConfiguration
• AntPluginTest#testCustomBuildFailDoesNotExist
• AntPluginTest#testWithAntPipelineBlock
• AntPluginTest#use_default_ant_installation
• SshSlavesPluginTest#connectWithEd25519EncKey
• SshSlavesPluginTest#connectWithKey
• SshSlavesPluginTest#connectWithPassword
• SshSlavesPluginTest#customJavaPath
• SshSlavesPluginTest#customStartup
• SshSlavesPluginTest#jvmOptions
• SshSlavesPluginTest#unableToConnectWrongCredentials
• SshSlavesPluginTest#unableToConnectWrongPort
• WorkflowPluginTest#sshGitInsideDocker
• XvncPluginTest#run_xvnc_during_the_build
• XvncPluginTest#use_specific_display_number
• XvncPluginTest#workflow

[basil]

Caused by jenkinsci/ssh-credentials-plugin#199 CC @olamy @Dohbedoh

[basil]

@olamy Since it was caused by jenkinsci/ssh-credentials-plugin#199, should this issue be assigned to you?

[jtnord]

I think at least some of this analysis is not correct and is actually #1526 which is somethinn that was broken in core. https://issues.jenkins.io/browse/JENKINS-72998
last run of master in CI was using 2.440.2 for LTS which is missing this fix.

[basil]

I think at least some of this analysis is not correct

@jtnord Which part of this analysis is not correct?

and is actually #1526 which is somethinn that was broken in core

Yes, core has long been broken, but this breakage wasn't exposed in a way that affected this test suite until jenkinsci/ssh-credentials-plugin#199.

[jtnord]

I think at least some of this analysis is not correct

@jtnord Which part of this analysis is not correct?

and is actually #1526 which is something that was broken in core

Yes, core has long been broken, but this breakage wasn't exposed in a way that affected this test suite until jenkinsci/ssh-credentials-plugin#199.

Exactly the test failure where revealed (or discovered) by the ssh-credential change, but caused by JENKINS-72998.

Anyway, I suppose not important.

Perhaps I should have left the other ticket open until JENKINS-72998 was cherry-picked or otherwise ended up in master to save any effort you or anyone else expended investigating this.

[basil]

@jtnord From https://bcantrill.dtrace.org/2015/09/03/software-immaculate-fetid-and-grimy/

Now on the one hand, this wasn’t entirely wrong: the change had been complicated and the subsystem that was being modified was a bit of a mess — and it was arguably a preexisting issue that had merely been exposed by the change. But on the other hand, it was the change that exposed it: the subsystem might have been brittle with respect to such changes, but it had at least worked correctly prior to it.

When a change exposes a preexisting issue that was previously unexposed, that is itself a regression — and a particularly severe one when it destabilizes a repository for months at a time, stopping all dependency updates and creating obstacles for anyone trying to use this repository's Jenkinsfile to test core PRs. In essence, it begins a downward spiral described here that is difficult to get out of — during the time period in question, no fewer than three additional regressions were introduced into this repository.