Windows agents connected to Jenkins by SSH hang when cloning an SSH repo from github.com

[akash-manna-sky]

Windows agents connected to Jenkins by SSH hang when cloning an SSH repo from github.com

Fixes #1715

Testing done

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[akash-manna-sky]

I just Reordered the SSH executable discovery logic on Windows to prefer the Git-for-Windows / MinGit ssh.exe over the first ssh.exe found on the system PATH. The system ssh.exe (e.g. Microsoft OpenSSH) is now used only as a fallback.

Microsoft OpenSSH can block in non-interactive CI environments, causing git fetch to hang. Git-for-Windows's ssh.exe is designed for non-interactive use and was used successfully in previous plugin versions. Restoring this priority fixes the regression while preserving backward compatibility.

@MarkEWaite

[MarkEWaite]

I just Reordered the SSH executable discovery logic on Windows to prefer the Git-for-Windows / MinGit ssh.exe over the first ssh.exe found on the system PATH. The system ssh.exe (e.g. Microsoft OpenSSH) is now used only as a fallback.

If we can't make it work reliably, I'd rather remove it than risk that users would be surprised to start using it.

Microsoft OpenSSH can block in non-interactive CI environments, causing git fetch to hang. Git-for-Windows's ssh.exe is designed for non-interactive use and was used successfully in previous plugin versions. Restoring this priority fixes the regression while preserving backward compatibility.

Could you check if there are command line arguments that can be passed to Microsoft OpenSSH that will cause it to not block in CI environments? I was aware of the -T argument, but there may be others.

[akash-manna-sky]

I just Reordered the SSH executable discovery logic on Windows to prefer the Git-for-Windows / MinGit ssh.exe over the first ssh.exe found on the system PATH. The system ssh.exe (e.g. Microsoft OpenSSH) is now used only as a fallback.

If we can't make it work reliably, I'd rather remove it than risk that users would be surprised to start using it.

Microsoft OpenSSH can block in non-interactive CI environments, causing git fetch to hang. Git-for-Windows's ssh.exe is designed for non-interactive use and was used successfully in previous plugin versions. Restoring this priority fixes the regression while preserving backward compatibility.

Could you check if there are command line arguments that can be passed to Microsoft OpenSSH that will cause it to not block in CI environments? I was aware of the -T argument, but there may be others.

I added command line argument. Please see.

[MarkEWaite]

I added command line argument. Please see.

For my convenience testing, could you put the PATH search back to the first in the list? That will allow me to test your pull request and confirm that it resolves the issue I saw in my testing, without major changes to my test environment.

[akash-manna-sky]

I added command line argument. Please see.

For my convenience testing, could you put the PATH search back to the first in the list? That will allow me to test your pull request and confirm that it resolves the issue I saw in my testing, without major changes to my test environment.

Please test it now.

[MarkEWaite]

Please test it now.

Please merge the latest changes from the master branch so that I have an incremental that includes the changes from the very recent 6.4.3 release.

[akash-manna-sky]

Please test it now.

Please merge the latest changes from the master branch so that I have an incremental that includes the changes from the very recent 6.4.3 release.

Done!

[MarkEWaite]

Unfortunately, it still hangs in my test environment. I think we should revert the change from the master branch so that the master branch is ready to release. You are welcome to continue exploring the change, but I think it is not yet ready to release.

[MarkEWaite]

Does not resolve the issue in my test environment.

[akash-manna-sky]

Unfortunately, it still hangs in my test environment. I think we should revert the change from the master branch so that the master branch is ready to release. You are welcome to continue exploring the change, but I think it is not yet ready to release.

Ok then can you please assign me or suggest me few backend related issues in this plugin or another plugin you maintained, it will be helpful for me to contribute? And also I have another two open PRs #1707 and #1713 in this plugin, it will be helpful if you review those PRs.

Thank you!

[MarkEWaite]

Ok then can you please assign me or suggest me few backend related issues in this plugin or another plugin you maintained, it will be helpful for me to contribute? And also I have another two open PRs #1707 and #1713 in this plugin, it will be helpful if you review those PRs.

I'm focused on completing the testing and other preparation for the release of git client plugin 6.5.0. I won't review those two pull requests until I've completed the release of git client plugin 6.5.0. I don't like to allow a long time between the release of a new JGit version and a matching release of the git client plugin.