One of the quirks of the pre-2.2.0 UI was that the purpose of alternative checkout credentials was unclear.

The chosen credentials need to be able to see all repositories and branches that they will check out.

The scan credentials have to be username & password (though the password can be an application token/password) and will only find repositories and branches that the scan credentials can find. The permission models are such that if you can find repositories and query the existence of a Jenkinsfile in those repositories, you have to have permission to check out those repositories and branches.

What use cases are there for specifying alternative checkout credentials? There was only one set of use cases that we could identify:

• You want to checkout over SSH using a SSH key

In every other use case, the scan credentials could be changed to the checkout credentials as username/password credentials valid for checking out will perform an equivalent scan / index.

Thus, as part of JENKINS-43507 the behaviour is "Checkout over SSH" and the credentials available for selection are limited to the SSH key credential types.

This gives rise to an issue:

• If the user had configured separate username / password credentials to be used for checkout (because let's face it, the old UI was exceedingly confusing around the purpose of Checkout Credentials) then due to the migration logic being invoked prior to the ability to resolve credentials, we will be unable to determine if the credential is a SSH key credential or a username / password credential. As a result a "Checkout over SSH" behaviour will be added, but the credential drop-down will be empty.

 To mitigate, we should make the following changes:

• If the checkout credentials have been specified and are exactly the same as the scan credentials, we can assume they are username/password credentials and not add the SSH Checkout behaviour
• We should add form validation to catch where the configured credentials for SSH checkout are not SSH keys or cannot be found.