[CLI and SSH] Linter plugin fails when a ~/.ssh/config exists

Question

[CLI and SSH] Linter plugin fails when a ~/.ssh/config exists

gpmayorga opened this issue 6 years ago · comments

After a long troubleshooting session (my Jenkins servers use Github Oauth, so the setup wasn't straight forward) I manage to get this working using "CLI and SSH", the only issue is that jenkins-cli.jar throws an INFO message if a ~/.ssh/config file exists:

guille$ java -jar ~/jenkins-cli.jar -s https://jenkins.paris-squad.com -ssh -user goperez -i ~/.ssh/jenkins-master declarative-linter < /Users/username/Projects/BuildJenkinsfile

Dec 05, 2018 6:31:15 PM org.apache.sshd.client.config.hosts.ConfigFileHostEntryResolver reloadHostConfigEntries
INFO: resolveEffectiveResolver(username@jenkins.myexample.com:2222) loaded 25 entries from /Users/guille/.ssh/config
Jenkinsfile successfully validated.

And it just so happens that your app considers this INFO message as an error and throws an exception:

[Linter] Error running Jenkins Error: Dec 05, 2018 6:36:25 PM org.apache.sshd.client.config.hosts.ConfigFileHostEntryResolver reloadHostConfigEntries
INFO: resolveEffectiveResolver(username@jenkins.myexample.com:2222) loaded 25 entries from /Users/username/.ssh/config
    at ChildProcess.<anonymous> (/Users/guille/.atom/packages/linter-jenkins/node_modules/sb-exec/lib/index.js:41)
    at emitTwo (events.js:126)
    at ChildProcess.emit (events.js:214)
    at maybeClose (internal/child_process.js:925)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:209)

I'm assuming this would be the case if Jenkins returns anything but the expected string through stdout. It's an edge corner but it also means the error handling is a little poor, totally worth looking into it (I would if I had more JS experience).

Thank you,

Matthew Schuchard · Answer 1 · Thu Dec 06 2018 20:24:11 GMT+0800 (China Standard Time)

I have seen something similar to this, because I was working on getting the linter working with automatic host authorization. What happens is those "INFO" messages from SSH are being returned as non-zero exit return values, so the underlying sb-exec backend npm treats them as failures. I tried circumventing this by allowing non-zero exit codes, but then errors become ignored, which becomes problematic for debugging.

This issue will likely be helpful when I revisit the related issue I saw. I was going to punt on it indefinitely, but it seems the problem arises in other situations and I can take a fresh look at it.

Matthew Schuchard · Answer 2 · Thu Dec 06 2018 23:54:31 GMT+0800 (China Standard Time)

I doublechecked my notes and actually it is because SSH is outputting that "INFO" statement to stderr and not because of a non-zero return value. Sub that in for my comments above.

Matthew Schuchard · Answer 3 · Fri Dec 07 2018 00:20:38 GMT+0800 (China Standard Time)

Workaround provided in fa76b3d. Please patch in the latest main.js to your local package at ~/.atom/packages, reload Atom, enable the new config option, and see if that fixes the issue for you. Make sure it works in both cases where the Jenkinsfile is valid and invalid.

Guillermo Perez · Answer 4 · Tue Jan 22 2019 09:25:13 GMT+0800 (China Standard Time)

I tried the new file, but no luck. I reloaded Atom twice just in case. Similar error appears:

/Users/guille/.atom/packages/linter/lib/linter-registry.js:159 [Linter] Error running Jenkins Error: Jan 21, 2019 8:19:45 PM org.apache.sshd.client.config.hosts.ConfigFileHostEntryResolver reloadHostConfigEntries
INFO: resolveEffectiveResolver(goperez@jenkins.paris-squad.com:2222) loaded 25 entries from /Users/guille/.ssh/config
    at ChildProcess.<anonymous> (/Users/guille/.atom/packages/linter-jenkins/node_modules/sb-exec/lib/index.js:41:20)
    at emitTwo (events.js:126:13)
    at ChildProcess.emit (events.js:214:7)
    at maybeClose (internal/child_process.js:925:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
(anonymous) @ /Users/guille/.atom/packages/linter/lib/linter-registry.js:159

Here's my ~/.ssh/config:

Host jenkins.dev.uts-squad.com
  hostname 192.168.10.8
  ProxyCommand ssh uts-bastion-dev -W %h:%p

Thank you for taking the time to try to solve this

Matthew Schuchard · Answer 5 · Tue Jan 22 2019 21:46:03 GMT+0800 (China Standard Time)

I will put this back on the TODOs. Thanks for providing the config so I can attempt to duplicate this.

Matthew Schuchard · Answer 6 · Wed Jan 23 2019 08:31:12 GMT+0800 (China Standard Time)

I just tested this and verified that Ignore stderr Output bypasses the issue with ssh outputting info and warning to stderr. Instead of the ssh message being thrown to the Atom error display, the linter diagnostic output is displayed as expected.

Sorry I cannot reproduce this when utilizing the fix I implemented for this.

Martin Nordsletten · Answer 7 · Tue Jan 29 2019 16:11:33 GMT+0800 (China Standard Time)

I think I am seeing the same problem. I'm not getting any errors in atom, but I'm not getting any linter output either.

When I enable the debug output and I copy paste the command it is running I get the response I would expect, it is just not translating properly into atom.

I also tried the patch and new option that was discussed, but I saw no difference. Still no error messages.

I am also using a .ssh/config where I've set up a proxyCommand, so it seems like our use cases are very similar.

Matthew Schuchard · Answer 8 · Tue Jan 29 2019 19:21:14 GMT+0800 (China Standard Time)

@mnordsletten You have a different situation since this issue is rooted in sb-exec treating all stderr file descriptor output as an error unless otherwise specified. Please open a new issue for your situation.

Matthew Schuchard · Answer 9 · Thu Feb 07 2019 21:04:16 GMT+0800 (China Standard Time)

Closing due to unable to reproduce and lack of update. Please request a re-open if necessary.