Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-68432

Misleading git plugin message when an unsupported credential type is used

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None
    • Jenkins Docker Image: jenkins/jenkins:lts-jdk11
      Jenkins 2.332.3

      The first stage of the pipeline needs to checkout the source code from a local GitLab.

      I created credentials of type "Secret Text" and scope "Global" in Jenkins, with id "gitlab_access_token". Unfortunately, the git plugin does not support "secret text" credentials. It only supports username / password credentials for https repository access and ssh private key credentials for ssh repository access.

      The error message that is displayed does not help the user understand that restriction. Either the git plugin should extend its support also allow "secret text" credentials for https repository access or it should provide a better error message that indicates the credential is not supported by the git plugin.

      When executing the pipeline I get the following error:

      Warning: CredentialId "gitlab_access_token" could not be found.

       

      If I change the credentials to "User and Password", the credentials Id does work.

       

      The pipeline is defined as follows:

      stages {
       stage("Code Checkout from GitLab") {
        steps {
         git branch: 'main',
          credentialsId: 'gitlab_access_token',

       

      It is not a blocker as I am still able to use some soft of authentication, but the purpose is to use Personal Access Tokens and not User Credentials, which is impossible due to this error.

      I have checked the Internet and other issues, but it does not seem to be the same problem as the ones that I found (sometimes similar, but not equal).

       

      I have also tried to use double quotes instead of single quotes for the id.

      Also left the input field empty so that the system assigned the id, and still it does not work.

       

      As a matter of fact, the credentials-plugin cannot be updated: 

          [JENKINS-68432] Misleading git plugin message when an unsupported credential type is used

          This is not a bug in the Credentials plugin. The "Secret Text" credential type is StringCredentialsImpl (javadoc), which implements neither of the StandardUsernamePasswordCredentials or SSHUserPrivateKey interfaces required by GitClient.CREDENTIALS_MATCHER (source), so the Credentials plugin correctly detects that the credential is not suitable.

          https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html looks like you should define a "Username with password" credential in which the username can be anything and the password is the personal access token.

          Kalle Niemitalo added a comment - This is not a bug in the Credentials plugin. The "Secret Text" credential type is StringCredentialsImpl ( javadoc ), which implements neither of the StandardUsernamePasswordCredentials or SSHUserPrivateKey interfaces required by GitClient.CREDENTIALS_MATCHER ( source ), so the Credentials plugin correctly detects that the credential is not suitable. https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html looks like you should define a "Username with password" credential in which the username can be anything and the password is the personal access token.

          As for updating the Credentials plugin: the newest version 1126.ve05618c41e62 requires Jenkins 2.340, and you have Jenkins 2.332.3, so you can't update the plugin yet. According to the Event Calendar, a new Jenkins LTS version should be released on June 1, 2022. All the versions proposed in Next LTS baseline are higher than 2.340.

          Kalle Niemitalo added a comment - As for updating the Credentials plugin: the newest version 1126.ve05618c41e62 requires Jenkins 2.340, and you have Jenkins 2.332.3, so you can't update the plugin yet. According to the Event Calendar , a new Jenkins LTS version should be released on June 1, 2022. All the versions proposed in Next LTS baseline are higher than 2.340.

          Hi Kalle, 

          Thanks a lot for your answer.

          You are completely right with both of your answers.

          Still the error that is reported in the console ouput is that the credentialsId cannot be found. I mean, the ID that has been created in the Credentials Manager section.

          Even if GitLab is unable to manage the secret as such (and reverts to user and token as password), I still believe that the message is wrong.

           

          I will update the issue removing the credentials-plugin component.

           

          Thank you very much for your support.

           

          Kind regards,

             Dani.

          Daniel Fernández Guerrero added a comment - Hi Kalle,  Thanks a lot for your answer. You are completely right with both of your answers. Still the error that is reported in the console ouput is that the credentialsId cannot be found. I mean, the ID that has been created in the Credentials Manager section. Even if GitLab is unable to manage the secret as such (and reverts to user and token as password), I still believe that the message is wrong.   I will update the issue removing the credentials-plugin component.   Thank you very much for your support.   Kind regards,    Dani.

          The "CredentialId "gitlab_access_token" could not be found" message seems to come from https://github.com/jenkinsci/git-plugin/blob/8d93ac3e1141c3e3f645569be9cfaa0cc9d61b62/src/main/java/hudson/plugins/git/GitSCM.java#L926, so git-plugin would be the correct component if you want to change the message.

          Kalle Niemitalo added a comment - The "CredentialId "gitlab_access_token" could not be found" message seems to come from https://github.com/jenkinsci/git-plugin/blob/8d93ac3e1141c3e3f645569be9cfaa0cc9d61b62/src/main/java/hudson/plugins/git/GitSCM.java#L926 , so git-plugin would be the correct component if you want to change the message.

          GitSCM.lookupScanCredentials would return null in these cases:

          • There is no credential with that ID anywhere.
          • The credential is in a credential store that CredentialsProvider.findCredentialById does not search for that Run.
          • The credential is in a credential domain that does not match the SCM URI.
          • The Run is not authorized to use the credential.
          • The credential does not implement the StandardUsernameCredentials interface, which GitSCM.lookupScanCredentials passes as an argument to CredentialsProvider.findCredentialById.
          • The credential does not implement either of the StandardUsernamePasswordCredentials or SSHUserPrivateKey interfaces, which GitSCM.lookupScanCredentials checks after CredentialsProvider.findCredentialById has returned.

          There may be multiple credentials with the same ID, in different credential stores or credential domains. If the job has a credential that has the expected ID but the wrong type, CredentialsProvider.findCredentialById might still find a suitable credential from a parent. So the Git plugin probably should not just call CredentialsProvider.findCredentialById with minimal requirements and then check whether the resulting credential is suitable in all respects. Instead, it could first try to find the credential in its current way, and then if that does not work, call CredentialsProvider.findCredentialById again with looser arguments in order to choose a suitable warning message.

          Kalle Niemitalo added a comment - GitSCM.lookupScanCredentials would return null in these cases: There is no credential with that ID anywhere. The credential is in a credential store that CredentialsProvider.findCredentialById does not search for that Run. The credential is in a credential domain that does not match the SCM URI. The Run is not authorized to use the credential. The credential does not implement the StandardUsernameCredentials interface, which GitSCM.lookupScanCredentials passes as an argument to CredentialsProvider.findCredentialById. The credential does not implement either of the StandardUsernamePasswordCredentials or SSHUserPrivateKey interfaces, which GitSCM.lookupScanCredentials checks after CredentialsProvider.findCredentialById has returned. There may be multiple credentials with the same ID, in different credential stores or credential domains. If the job has a credential that has the expected ID but the wrong type, CredentialsProvider.findCredentialById might still find a suitable credential from a parent. So the Git plugin probably should not just call CredentialsProvider.findCredentialById with minimal requirements and then check whether the resulting credential is suitable in all respects. Instead, it could first try to find the credential in its current way, and then if that does not work, call CredentialsProvider.findCredentialById again with looser arguments in order to choose a suitable warning message.

          Brilliant answer, thank you very much indeed.

          You encourage me to look into these things deeper.

          It is much appreciated.

          Daniel Fernández Guerrero added a comment - Brilliant answer, thank you very much indeed. You encourage me to look into these things deeper. It is much appreciated.

            Unassigned Unassigned
            danifgx Daniel Fernández Guerrero
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: