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

Cannot bind folder credentials to pipeline shared library using Modern SCM option

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Labels:
      None
    • Environment:
      Windows Server 2012 R2 64 Bit
      Java SE 1.8.0_144
      Jenkins 2.60.2 (running as Windows service)
      Pipeline: Shared Groovy Libraries 2.8
      Credentials Plugin 2.1.14
    • Similar Issues:

      Description

      When adding a Jenkins shared library in a folder, the Modern SCM (using Git) option does not show credentials that are defined in that folder (the list is instead empty).

      With the Legacy SCM option, I can use credentials from the folder and everything works as expected.

        Attachments

          Issue Links

            Activity

            procom_bl Thomas Bächler created issue -
            stephenconnolly Stephen Connolly made changes -
            Field Original Value New Value
            Component/s git-plugin [ 15543 ]
            Component/s credentials-plugin [ 16523 ]
            stephenconnolly Stephen Connolly made changes -
            Assignee Stephen Connolly [ stephenconnolly ]
            Hide
            stephenconnolly Stephen Connolly added a comment -

            Unclear the root of this context information being unavailable... could be the git plugin at issue or could be how the global libraries hack form binding. Nothing to do with the credentials plugin in any case

            Show
            stephenconnolly Stephen Connolly added a comment - Unclear the root of this context information being unavailable... could be the git plugin at issue or could be how the global libraries hack form binding. Nothing to do with the credentials plugin in any case
            Hide
            markewaite Mark Waite added a comment -

            I believe this is resolved in git plugin 3.5.1. Thomas Bächler could you confirm it?

            Show
            markewaite Mark Waite added a comment - I believe this is resolved in git plugin 3.5.1. Thomas Bächler could you confirm it?
            markewaite Mark Waite made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            markewaite Mark Waite made changes -
            Link This issue duplicates JENKINS-44271 [ JENKINS-44271 ]
            Hide
            procom_bl Thomas Bächler added a comment - - edited

            I can configure the "Modern SCM" with the folder credentials option now, but it still does not work.

            Authentication fails when verifying the default version in the configuration and building a job also fails (it works when using Legacy SCM, with the same credentials):

            Loading library LibraryName@master
            > git.exe rev-parse --is-inside-work-tree # timeout=10
            Setting origin to https://[...].git
            > git.exe config remote.origin.url https://[...].git # timeout=10
            Fetching origin...
            Fetching upstream changes from origin
            > git.exe --version # timeout=10
            > git.exe fetch --tags --progress origin +refs/heads/:refs/remotes/origin/
            hudson.plugins.git.GitException: Command "git.exe fetch --tags --progress origin +refs/heads/:refs/remotes/origin/" returned status code 128:
            stdout:
            stderr: fatal: Authentication failed for 'https://[...].git/'

            Show
            procom_bl Thomas Bächler added a comment - - edited I can configure the "Modern SCM" with the folder credentials option now, but it still does not work. Authentication fails when verifying the default version in the configuration and building a job also fails (it works when using Legacy SCM, with the same credentials): Loading library LibraryName@master > git.exe rev-parse --is-inside-work-tree # timeout=10 Setting origin to https://[...].git > git.exe config remote.origin.url https://[...].git # timeout=10 Fetching origin... Fetching upstream changes from origin > git.exe --version # timeout=10 > git.exe fetch --tags --progress origin +refs/heads/ :refs/remotes/origin/ hudson.plugins.git.GitException: Command "git.exe fetch --tags --progress origin +refs/heads/ :refs/remotes/origin/ " returned status code 128: stdout: stderr: fatal: Authentication failed for 'https://[...].git/'
            Hide
            markewaite Mark Waite added a comment -

            Thomas Bächler I didn't expect significant differences between the authentication used in "Legacy SCM" or in "Modern SCM". Can you confirm that you're using the same URL in both cases?

            Are there any items of interest about the credentials you're using? For example, does the password contain characters which might be special to the shell (indicating a shell expansion bug in credential handling in the plugin)?

            Show
            markewaite Mark Waite added a comment - Thomas Bächler I didn't expect significant differences between the authentication used in "Legacy SCM" or in "Modern SCM". Can you confirm that you're using the same URL in both cases? Are there any items of interest about the credentials you're using? For example, does the password contain characters which might be special to the shell (indicating a shell expansion bug in credential handling in the plugin)?
            Hide
            procom_bl Thomas Bächler added a comment -

            Same URL and same credentials in both cases.

            It is interesting to note that when using the Legacy SCM variant, Jenkins says "using GIT_ASKPASS to set credentials <Credential Name>" before the git fetch command, while in the Modern SCM case (see above), it doesn't (indicating that Jenkins does not even try to use credentials).

            I have another Jenkins library, in the global configuration using global credentials (no folders involved) where I successfully use the Modern SCM plugin. Jenkins also prints the "using GIT_ASKPASS" line there.

            Show
            procom_bl Thomas Bächler added a comment - Same URL and same credentials in both cases. It is interesting to note that when using the Legacy SCM variant, Jenkins says "using GIT_ASKPASS to set credentials <Credential Name>" before the git fetch command, while in the Modern SCM case (see above), it doesn't (indicating that Jenkins does not even try to use credentials). I have another Jenkins library, in the global configuration using global credentials (no folders involved) where I successfully use the Modern SCM plugin. Jenkins also prints the "using GIT_ASKPASS" line there.
            Hide
            markewaite Mark Waite added a comment -

            I wonder if that indicates some bug in the plugin's handling of credential scope? You've said that the same credentials are being used. I assume that means the credentials are visible and selected in the job configuration page.

            Is there anything on that particular credential which might cause it to be excluded from use in that context, but allowed to be used in other contexts?

            Forgive my wild guesses, but I'm perplexed why it works for you in some cases and not in others, and works for me in all cases.

            Show
            markewaite Mark Waite added a comment - I wonder if that indicates some bug in the plugin's handling of credential scope? You've said that the same credentials are being used. I assume that means the credentials are visible and selected in the job configuration page. Is there anything on that particular credential which might cause it to be excluded from use in that context, but allowed to be used in other contexts? Forgive my wild guesses, but I'm perplexed why it works for you in some cases and not in others, and works for me in all cases.
            Hide
            procom_bl Thomas Bächler added a comment -

            Just to be clear (because it might have been confusing above), everything works fine for GLOBAL libraries and credentials (both legacy and modern scm), but modern scm fails for FOLDER libraries and credentials. That failure (as mentioned earlier) occurs in the configuration page when the default version is resolved AND when trying to build a job.

            The credentials are visible in the folder shared library configuration (for both legacy and modern SCM). In both tests, I selected those same credentials. It is a standard username/password pair which is scoped to that particular folder. We use those credentials for git checkouts for virtually every job in that folder (and in subfolders).

            The username and password are ASCII only, although I think that the password contains a '!'.

            Show
            procom_bl Thomas Bächler added a comment - Just to be clear (because it might have been confusing above), everything works fine for GLOBAL libraries and credentials (both legacy and modern scm), but modern scm fails for FOLDER libraries and credentials. That failure (as mentioned earlier) occurs in the configuration page when the default version is resolved AND when trying to build a job. The credentials are visible in the folder shared library configuration (for both legacy and modern SCM). In both tests, I selected those same credentials. It is a standard username/password pair which is scoped to that particular folder. We use those credentials for git checkouts for virtually every job in that folder (and in subfolders). The username and password are ASCII only, although I think that the password contains a '!'.
            Hide
            markewaite Mark Waite added a comment -

            Thanks for the clarification. I think I've made a mistake in earlier comments. I believe all of my pipeline library repositories are public, so my testing (to date) of this bug report has not been testing authentication. I'll have to double check when I spend more time on this.

            Show
            markewaite Mark Waite added a comment - Thanks for the clarification. I think I've made a mistake in earlier comments. I believe all of my pipeline library repositories are public, so my testing (to date) of this bug report has not been testing authentication. I'll have to double check when I spend more time on this.
            Hide
            jacobtruman Jacob Truman added a comment -

            I see that this was resolved, but I do not see what the resolution was? I have the git plugin 3.5.1 installed and am having the same issue:

            GLOBAL credentials DO work on Modern and Legacy SCM

            FOLDER credentials DO NOT work on Modern SCM

            FOLDER credentials DO work on Legacy SCM

            Show
            jacobtruman Jacob Truman added a comment - I see that this was resolved, but I do not see what the resolution was? I have the git plugin 3.5.1 installed and am having the same issue: GLOBAL credentials DO work on Modern and Legacy SCM FOLDER credentials DO NOT work on Modern SCM FOLDER credentials DO work on Legacy SCM
            Hide
            markewaite Mark Waite added a comment - - edited

            I presume it was resolved as a duplicate of JENKINS-44271, which was included in git plugin 3.5.1.  

            This bug is not mentioned in the git plugin changelog, so it may be that this is a different bug than JENKINS-44271.

            Since you're seeing that it does not work for you, please reopen the issue, and double check that the bug description accurately reflects the steps you take to see the bug.

            Show
            markewaite Mark Waite added a comment - - edited I presume it was resolved as a duplicate of JENKINS-44271 , which was included in git plugin 3.5.1.   This bug is not mentioned in the git plugin changelog , so it may be that this is a different bug than JENKINS-44271 . Since you're seeing that it does not work for you, please reopen the issue, and double check that the bug description accurately reflects the steps you take to see the bug.
            Hide
            jacobtruman Jacob Truman added a comment -

            It looks like this (and my) issue is very similar to JENKINS-43802

            Show
            jacobtruman Jacob Truman added a comment - It looks like this (and my) issue is very similar to JENKINS-43802
            Hide
            procom_bl Thomas Bächler added a comment -

            Credentials now show in the configuration, but are not used when checking out the library. Anyway, this is tracked in JENKINS-43802, so there is no need to reopen this issue.

            Show
            procom_bl Thomas Bächler added a comment - Credentials now show in the configuration, but are not used when checking out the library. Anyway, this is tracked in JENKINS-43802 , so there is no need to reopen this issue.
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

              People

              • Assignee:
                Unassigned
                Reporter:
                procom_bl Thomas Bächler
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: