Task/jenkins 42120 git creation credential changes

[cliffmeyers]

Description

• Includes changes from JENKINS-41397# validate git credential #759
• See JENKINS-42120.

Submitter checklist

• Link to JIRA ticket in description, if appropriate.
• Change is code complete and matches issue description
• Appropriate unit or acceptance tests or explanation to why this change has no tests
• Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.
• Ran Acceptance Test Harness against PR changes.

Reviewer checklist

• Run the changes and verified the change matches the issue description
• Reviewed the code
• Verified that the appropriate tests have been written or valid explanation given

[michaelneale]

• There is no "use system ssh" any more? (I think in ticket it says don't need to use that, but not sure if that is valid...). But I am not sure what it meant in classic anyway so... maybe not a huge deal
• I wasn't able to make it work with a private key and a git@url. I renamed my ~/.ssh/id_rsa to something so the system wouldn't pick it up - but pasting it in didn't work. That window is far too small for a private key (I am not sure if a dialog is the best for that) so I can't tell if something messed up formatting, but it didn't work.
• I end up with lots of "michaelneale" named credentials in the list that I can't tell apart trying the above (no way to easily remove them)
• I tried using username and password with git@ style - and it didn't work (should that case?)

So basically - I don[t think the git@ case is working in the current form for this at all.

HTTP case worked, but not git@.

[michaelneale]

EDIT: in previous version, ssh private key didn't work correctly either. The easiest way to test is just to rename your ssh key in ~/.ssh so you know it isn't being used.

[michaelneale]

• I tried the latest and it works with private key, however if I use "none" (the equivalent of system?) it says it is not a valid URL, but in the server log I see it is credentials related:

Mar 13, 2017 4:38:24 PM io.jenkins.blueocean.blueocean_git_pipeline.GitUtils validateCredentials
SEVERE: Error running git remote-ls: Cannot open session, connection is not authenticated.
java.lang.IllegalStateException: Cannot open session, connection is not authenticated.
	at com.trilead.ssh2.Connection.openSession(Connection.java:1127)

So this seems a regression from how it was previously, I would think?

This is one area where I think the lack of ATH/automated testing is slowing us down in moving it forward, unfortunately.

• Also, once I pick a credential, I can't go back to "none".
• The lack of meaningfully named credentials makes this a bit of a mess pretty quickly:
  

This may bite me more in testing as it is contrived, but it makes it pretty much impossible to reuse things (not part of this PR really - just is very apparent). I not longer reuse credentials as there are too many from my testing 😭

If you can make it work with system ssh - then might be close enough for rock n roll.

[cliffmeyers]

@michaelneale good catches. Will look into the validation field mismatch. The "none" option was a bad assumption on my part about how to handle it, will fix that too.

Realized also that Dropdown needs a couple of tweaks to really polish it up, so I'm going to do that today too in a separate JDL PR.

[cliffmeyers]

@michaelneale both issues should now be fixed.

[michaelneale]

@cliffmeyers I still can't use git@github.com:multibranchorg/newbie.git

with the "none" credential - but it should default to using the system right?

Mar 14, 2017 11:30:40 AM io.jenkins.blueocean.blueocean_git_pipeline.GitUtils validateCredentials
SEVERE: Error running git remote-ls: Cannot open session, connection is not authenticated.
java.lang.IllegalStateException: Cannot open session, connection is not authenticated.
	at com.trilead.ssh2.Connection.openSession(Connection.java:1127)
	at org.jenkinsci.plugins.gitclient.trilead.TrileadSession.exec(TrileadSession.java:32)
	at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:264)
	at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:162)
	at org.eclipse.jgit.api.LsRemoteCommand.execute(LsRemoteCommand.java:198)
	at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:159)
	at org.jenkinsci.plugins.gitclient.JGitAPIImpl.getRemoteReferences(JGitAPIImpl.java:768)
	at io.jenkins.blueocean.blueocean_git_pipeline.GitUtils.validateCredentials(GitUtils.java:48)
	at io.jenkins.blueocean.blueocean_git_pipeline.GitPipelineCreateRequest.validate(GitPipelineCreateRequest.java:125)
	at io.jenkins.blueocean.blueocean_git_pipeline.GitPipelineCreateRequest.<init>(GitPipelineCreateRequest.java:45)

on server.

The error message is better now - says it is credential error vs url error... so that is good at least, but something isn't right with the system credential "none" option.

[michaelneale]

@cliffmeyers yes I confirmed with master that if it says "system" it would use my id_rsa as I expect, from disk, and I could clone private repos via ssh.

"none" in this case does not behave like that - is that intended?

[michaelneale]

I checked with classic, and "none" actually means none - ie it will delegate to the id on the system via the git client, not jenkins internal key.

So this is not consistent behavior with previous master or classic - @vivek may need to tweak that assuming it is on the server side (probably is).

[i386]

@cliffmeyers where does the name 'none' come from? Can we make the name reflect what credential it is? It would be good to italicise its name in the dropdown to differentiate it from user defined credentials.

[cliffmeyers]

@i386 credential of "none" is exactly that: calling the creation API with a null credentialId. I can style the text no problem.

@MichaelNeal @i386 @vivek at this point I don't know exactly how to proceed. I guess we have the following questions:

• When the user chooses "none", what does that mean? I took it as "no credential." If that's the case, we need to figure out why we receive a SSH error when trying to connect. @vivek is that expected? Do all SCM checkouts over SSH require that a public key be sent? I suppose they might, actually?
• Should "none" actually use some other credential, transparent to the user? Would it be the master's "default SSH key"? If so, @vivek can you confirm that's the credential we needed to create via the REST API? And is that SSH key something that Jenkins is generating itself, or is that picking up the key from ~/.ssh?
• Lastly, if the answer to the above is "no", then should we assume that any keys in ~/.ssh should never automatically be picked up by Jenkins SCM operations?

[vivek]

If that's the case, we need to figure out why we receive a SSH error when trying to connect. @vivek is that expected? Do all SCM checkouts over SSH require that a public key be sent? I suppose they might, actually?

Thats right, if you access git over ssh protocol, you need to provide your ssh keys, even for public repos.

Should "none" actually use some other credential, transparent to the user? Would it be the master's "default SSH key"? If so, @vivek can you confirm that's the credential we needed to create via the REST API? And is that SSH key something that Jenkins is generating itself, or is that picking up the key from ~/.ssh?

I am confused. Just send null credentialId if user doesn't provide any credential, then all the defaulting behavior will be as per underlying branch-source plugin.

Lastly, if the answer to the above is "no", then should we assume that any keys in ~/.ssh should never automatically be picked up by Jenkins SCM operations?

Check the classic defaulting behavior thats what will happen in this case as well.

[cliffmeyers]

@vivek thanks, this makes sense now. I will follow up with a side conversation to get UI nailed down.

[michaelneale]

@cliffmeyers @vivek I think "none" (even if we tweak the exact name) should work the same as running:

"git clone git@thing.com/bar.git"

ie, it is up to my system config to decide what public key to use (for me that is ~/.ssh/config - which says to use id_rsa for github.com addresses).

Not sure if it shoudl be called "none" or something else, but that would make it consistent at least.

[cliffmeyers]

@michaelneale ready for re-test now.

[michaelneale]

This will need a master bump to pass the ATH as there was a recent merge for functionality around artifacts and the ATH. This requires a small change in master behavior which is not here (hence ATH fails).

[michaelneale]

@cliffmeyers if you update to master to get ATH to pass - I think this can go in if it sniffs ok. Assume a 🐝 if all checks out.

[cliffmeyers]

ATH passed: https://ci.blueocean.io/blue/organizations/jenkins/ATH-Jenkinsfile/detail/master/1842/pipeline/17