ehamric Even I am trying to understand more about this behavior, but so far my understanding was that for these kind of quick commands like less than mill seconds there is always a chance that file streams would get close before the entire output being sent to it. so kind of hack but thats the option that we are using, as it is just a couple of seconds for the job that we are running for hours

Thanks for your help    Should we leave the bug here with ssh-steps, or change it to core for further investigation?

Don't know if I can do anything about this at the moment, I will add some docs with the next release.

Closing this now, probably once it is becomes really problematic I will reopen or create a new one. Thanks for reporting ehamric.

Hello,

Well, I really don't understand how you can consider this as not problematic.
It is really a pain indeed !

Let's consider a user who wants to make some quick trials, or even a user who tries to avoid using a shell step with some more or less complex script to simply test a ssh connection. He finds the sshCommand and thinks ok, great ! I found what I need ! I have a simple way of testing, enclosing the sshCommand within a try / catch and calling a simple uname or ls command.
... But he is totally disappointed because ... ok, there is no problem. It seems to work, but he is not sure because he has no output. And he need the output fir this or that reason because he wants to check something.

That's my use case... even worst in fact. Because my organisation wants to set a bunch of test cases to validate the ssh step in order to be sure it can be used it in production, and later on to have some regression tests when upgrading jenkins and plugins. And at the first trial, I fall into this trap.

How can I say to people supporting Jenkins... hey men, that's OK. It works as a charm and everybody can use it with no worries !

So, no, it is not a cosmetic problem. It is a real one because it is more or less related to some unpredictable response time. I am not sure if 5 sec is enough. Perhaps it is less (and I loose time) perhaps it is more, and I both loose information and fail a test which is actually a success.

Besides, it transfers the responsibility of ensuring the complete achievement of the step to the caller. I cannot really consider this as a normal situation.

So, please, could you consider again this as bug to fix ?

Thanks for your help.
Best Regards

jlpinardon Thank you for the feedback.

JENKINS-59781 There is another JIRA logged for this problem, I am suggesting the same solution over there too, and I tried a couple of options and so far no luck. I will post more details on that JIRA once I know some good news. you are welcome to help if you would like to, please.

I can add sleep to the code inside the step but that would delay the entire pipeline execution a lot when the actual pipeline is using this step several times, is the reason I am suggesting it as a hacky solution to users for now.

There are a bunch of ways how we can test Jenkins pipelines in general, but what we do at our organization is we write unit test cases using https://github.com/homeaway/jenkins-spock and also we have test pipeline jobs with several use cases to regression test few of these important plugins.

And I doubt if I have answers to your other general questions except I trust Jenkins cause it gives me the flexibility/pride that I am a Developer. Thanks again.

I, too, see the issue with the highly asynchronous log output of this plugin. Even status logging (for example: "Executing command on name[server]: mycommand sudo: false")  is highly out of sync to the rest of the log (and sometimes doesn't get logged at all), making the log very confusing to read. This is an issue with this plugin, because these messages are written by the plugin itself. This doesn't have anything to do with the underlying groovy-ssh library.

Looking at the code, it seems to me that the likely issue is a missing flush()-call to the CustomLogHandler (or maybe the rootLogger) at the end of this method: https://github.com/jenkinsci/ssh-steps-plugin/blob/c35e7db86e975b257343179fd4f08dd0af8cbb42/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L55

That being said.. Is it really a good Idea to register a new CustomLogHandler every time something gets logged? The rootLogger is most likely static, so adding new handlers for each and every message will eventually lead to a ton of CustomLogHandlers that are probably never garbage collected.

sshCommand is useless if we cannot get stdout in pipeline. I need to retrieve information from remote server and I don't want to run sshCommand which generate temporary file and sshGet it

i am using ssh pipeline steps 2.0 version, and i dont see any possibility to capture the ouput of sshCommand, is this implemented? let us know.

I have the same problem. Figured out myself to use sleep at the end of the bash script I execute remotely via ssh. But also I have a trap function that executes on the script end. It does stop and remove the docker container. And I am able to see the output in the console, but not in Jenkins from sshCommand. Seems like Jenkins cuts the output in about the last 200-500ms.

L V Prasad, you can capture sshCommand output in this way.

def remote = [:]
remote.name = 'UAT'
remote.host = 'test.domain'
remote.user = 'username'
remote.password = 'pass'
remote.allowAnyHosts = true
stage('Remote SSH') {
   def commandResult = sshCommand remote: remote, command: "ls -ll"
   echo "Result: " + commandResult
}

but the problem is that output will not be full from the remote command.
This is the problem we discuss in this ticket.