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

Credentials dropdowns empty when configuring external libraries at the global level

    XMLWordPrintable

Details

    Description

      Adding a "Legacy SCM" git repository.

      The credentials ID drop down does not populate from existing items, nor do new items get added if I add them while editing the configuration.

      Console messages

      These may or may not be relevant (they seem relevant to me)

      hudson-behavior.js:417 Uncaught TypeError: Cannot read property 'firstChild' of undefinedregisterValidator @ hudson-behavior.js:417(anonymous function) @ behavior.js:111(anonymous function) @ behavior.js:107applySubtree @ behavior.js:93(anonymous function) @ select.js:251
      
      hudson-behavior.js:472 Unable to find nearby scm/id
      

      fillCredentialItems

      After adding a new credential item, the following calls were made - it seems like a weird set of items to fill (but I'm not jenkins rpc call savvy) - almost like it wasn't even calling to fill this dropdown.

      http://localhost:8080/descriptorByName/org.jenkinsci.plugins.github.config.HookSecretConfig/fillCredentialsIdItems
      http://localhost:8080/descriptorByName/hudson.plugins.git.UserRemoteConfig/fillCredentialsIdItems
      

      Attachments

        Issue Links

          Activity

            jglick Jesse Glick added a comment -

            I suppose you are talking about a global library, rather than a folder-scoped library?

            So the lack of credentialsId is a bug in the git plugin, in UserRemoteConfig.DescriptorImpl.doFillCredentialsIdItems. If project == null, it should offer global credentials, assuming you have Jenkins.ADMINISTER (I suppose). To make that easier, in credentials, includeMatchingAs should accept context == null.

            Unable to find nearby scm/id looks like a bug in this plugin, though it does not appear to break anything. TypeError: Cannot read property 'firstChild' of undefined I need to analyze.

            jglick Jesse Glick added a comment - I suppose you are talking about a global library, rather than a folder-scoped library? So the lack of credentialsId is a bug in the git plugin, in UserRemoteConfig.DescriptorImpl.doFillCredentialsIdItems . If project == null , it should offer global credentials, assuming you have Jenkins.ADMINISTER (I suppose). To make that easier, in credentials , includeMatchingAs should accept context == null . Unable to find nearby scm/id looks like a bug in this plugin, though it does not appear to break anything. TypeError: Cannot read property 'firstChild' of undefined I need to analyze.
            jglick Jesse Glick added a comment -

            Same applies to GitSCMSource, which you would be using if my PR to the git plugin were merged.

            jglick Jesse Glick added a comment - Same applies to GitSCMSource , which you would be using if my PR to the git plugin were merged.
            jglick Jesse Glick added a comment -

            Same applies in the subversion plugin and probably others as well.

            jglick Jesse Glick added a comment - Same applies in the subversion plugin and probably others as well.
            jglick Jesse Glick added a comment -

            In another context I get TypeError: Cannot read property 'value' of undefined from select.js:46 but I am not sure if it is related to global libraries. Unfortunately the Jenkins form JavaScript does no sanity checking whatsoever and so freely throws errors with no diagnostic information whenever anything is amiss.

            jglick Jesse Glick added a comment - In another context I get TypeError: Cannot read property 'value' of undefined from select.js:46 but I am not sure if it is related to global libraries. Unfortunately the Jenkins form JavaScript does no sanity checking whatsoever and so freely throws errors with no diagnostic information whenever anything is amiss.
            jglick Jesse Glick added a comment -

            Until maintainers of SCM plugins merge and release my PRs, workarounds would include:

            • using folder-scoped (untrusted) libraries, rather than global
            • using repositories that can be checked out anonymously, or using credentials stored at the OS level on the Jenkins master
            • editing $JENKINS_HOME/org.jenkinsci.plugins.workflow.libs.GlobalLibraries.xml to include the desired credentialsId, then restarting Jenkins
            jglick Jesse Glick added a comment - Until maintainers of SCM plugins merge and release my PRs, workarounds would include: using folder-scoped (untrusted) libraries, rather than global using repositories that can be checked out anonymously, or using credentials stored at the OS level on the Jenkins master editing $JENKINS_HOME/org.jenkinsci.plugins.workflow.libs.GlobalLibraries.xml to include the desired credentialsId , then restarting Jenkins
            bwalding Ben Walding added a comment -

            I was able to add the credentialsId to the xml config and reload to get me past this problem.

            It also seems that the legacy git provider won't do substitution of ${library.cloudbees-jenkins-ops-library.version} into the branch specifier. But I'll wait for the rest of the fixes to go through before I investigate that more thoroughly. I worked around that by hardcoding the version into the library.

            e.g.

             > git rev-parse refs/remotes/origin/${library.app.version}^{commit} # timeout=10
             > git rev-parse refs/remotes/origin/origin/${library.app.version}^{commit} # timeout=10
             > git rev-parse origin/${library.app.version}^{commit} # timeout=10
            ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
            
            bwalding Ben Walding added a comment - I was able to add the credentialsId to the xml config and reload to get me past this problem. It also seems that the legacy git provider won't do substitution of ${library.cloudbees-jenkins-ops-library.version} into the branch specifier. But I'll wait for the rest of the fixes to go through before I investigate that more thoroughly. I worked around that by hardcoding the version into the library. e.g. > git rev-parse refs/remotes/origin/${library.app.version}^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/${library.app.version}^{commit} # timeout=10 > git rev-parse origin/${library.app.version}^{commit} # timeout=10 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

            Is this also the reason why I can not anymore select globally defined credentials from the dropdown (git plugin) ?

            lifeofguenter Günter Grodotzki added a comment - Is this also the reason why I can not anymore select globally defined credentials from the dropdown (git plugin) ?
            jglick Jesse Glick added a comment -

            add the credentialsId to the xml config

            Specifically should look like

            <credentialsId>something-here</credentialsId>
            

            where the ID would either be something you picked when creating the credentials, or a generated UUID. The exact placement will depend on the SCM, so you need to consult an example of a freestyle project configuration.

            the legacy git provider won't do substitution

            Yes it does; this is tested. I suspect you mistyped the library name in the variable.

            why I can not anymore select globally defined credentials from the dropdown

            Not sure what you are referring to. This issue only refers to a lack of support for credentials dropdowns in a newly added feature, Pipeline library definitions in the global system configuration. Anything else is unrelated.

            jglick Jesse Glick added a comment - add the credentialsId to the xml config Specifically should look like <credentialsId> something-here </credentialsId> where the ID would either be something you picked when creating the credentials, or a generated UUID. The exact placement will depend on the SCM, so you need to consult an example of a freestyle project configuration. the legacy git provider won't do substitution Yes it does; this is tested. I suspect you mistyped the library name in the variable. why I can not anymore select globally defined credentials from the dropdown Not sure what you are referring to. This issue only refers to a lack of support for credentials dropdowns in a newly added feature, Pipeline library definitions in the global system configuration. Anything else is unrelated.
            marcus_phi Marcus Philip added a comment -

            I think JENKINS-38272 is a duplicate

            marcus_phi Marcus Philip added a comment - I think JENKINS-38272 is a duplicate
            marcus_phi Marcus Philip added a comment -

            jglick I cannot get your workaround to work:

            I have added credentialsId to org.jenkinsci.plugins.workflow.libs.GlobalLibraries.xml:

            <org.jenkinsci.plugins.workflow.libs.GlobalLibraries plugin="workflow-cps-global-lib@2.3">
              <libraries>
                <org.jenkinsci.plugins.workflow.libs.LibraryConfiguration>
                  <name>netentNGPCoreLib</name>
                  <retriever class="org.jenkinsci.plugins.workflow.libs.SCMRetriever">
                    <scm class="hudson.plugins.git.GitSCM" plugin="git@3.0.0">
                      <configVersion>2</configVersion>
                      <userRemoteConfigs>
                        <hudson.plugins.git.UserRemoteConfig>
                          <url>https://git.netent.com/scm/ngp/jenkins-workflow-libs.git</url>
                          <credentialsId>myCredentialsId</credentialsId>
                        </hudson.plugins.git.UserRemoteConfig>
                      </userRemoteConfigs>
                      <branches>
                        <hudson.plugins.git.BranchSpec>
                          <name>refs/heads/${library.netentNGPCoreLib.version}</name>
                          ...
            

            and run 'Reload Configuration from Disk', but I still get error:

            Loading library netentNGPCoreLib@master
             > /opt/rh/git19/root/usr/bin/git rev-parse --is-inside-work-tree # timeout=10
            Fetching changes from the remote Git repository
             > /opt/rh/git19/root/usr/bin/git config remote.origin.url https://git.netent.com/scm/ngp/jenkins-workflow-libs.git # timeout=10
            Fetching upstream changes from https://git.netent.com/scm/ngp/jenkins-workflow-libs.git
             > /opt/rh/git19/root/usr/bin/git --version # timeout=10
             > /opt/rh/git19/root/usr/bin/git fetch --tags --progress https://git.netent.com/scm/ngp/jenkins-workflow-libs.git +refs/heads/*:refs/remotes/origin/*
            ERROR: Error fetching remote repo 'origin'
            hudson.plugins.git.GitException: Failed to fetch from https://git.netent.com/scm/ngp/jenkins-workflow-libs.git
            	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:797)
            	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1051)
            	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1082)
            	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
            	at org.jenkinsci.plugins.workflow.libs.SCMSourceRetriever.doRetrieve(SCMSourceRetriever.java:102)
            	at org.jenkinsci.plugins.workflow.libs.SCMRetriever.retrieve(SCMRetriever.java:58)
            	at org.jenkinsci.plugins.workflow.libs.LibraryAdder.retrieve(LibraryAdder.java:150)
            	at org.jenkinsci.plugins.workflow.libs.LibraryAdder.add(LibraryAdder.java:131)
            	at org.jenkinsci.plugins.workflow.libs.LibraryDecorator$1.call(LibraryDecorator.java:99)
            	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:970)
            	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:548)
            	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:526)
            	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:503)
            	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:302)
            	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:281)
            	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731)
            	at groovy.lang.GroovyShell.parse(GroovyShell.java:743)
            	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
            	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410)
            	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373)
            	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213)
            	at hudson.model.ResourceController.execute(ResourceController.java:98)
            	at hudson.model.Executor.run(Executor.java:410)
            Caused by: hudson.plugins.git.GitException: Command "/opt/rh/git19/root/usr/bin/git fetch --tags --progress https://git.netent.com/scm/ngp/jenkins-workflow-libs.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
            stdout: 
            stderr: fatal: Authentication failed for 'https://git.netent.com/scm/ngp/jenkins-workflow-libs.git/'
            
            	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1752)
            	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1495)
            	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:64)
            	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:315)
            	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:795)
            	... 22 more
            ERROR: null
            org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
            WorkflowScript: Loading libraries failed
            
            1 error
            
            	at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:302)
            	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:997)
            	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:548)
            	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:526)
            	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:503)
            	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:302)
            	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:281)
            	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731)
            	at groovy.lang.GroovyShell.parse(GroovyShell.java:743)
            	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
            	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410)
            	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373)
            	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213)
            	at hudson.model.ResourceController.execute(ResourceController.java:98)
            	at hudson.model.Executor.run(Executor.java:410)
            Finished: FAILURE
            

            The credentials are used in other places so they should work.

            Noteworthy may be that when I go to global config page, I do not see the credentials in the dropdown.

            marcus_phi Marcus Philip added a comment - jglick I cannot get your workaround to work: I have added credentialsId to org.jenkinsci.plugins.workflow.libs.GlobalLibraries.xml: <org.jenkinsci.plugins.workflow.libs.GlobalLibraries plugin= "workflow-cps-global-lib@2.3" > <libraries> <org.jenkinsci.plugins.workflow.libs.LibraryConfiguration> <name> netentNGPCoreLib </name> <retriever class= "org.jenkinsci.plugins.workflow.libs.SCMRetriever" > <scm class= "hudson.plugins.git.GitSCM" plugin= "git@3.0.0" > <configVersion> 2 </configVersion> <userRemoteConfigs> <hudson.plugins.git.UserRemoteConfig> <url> https://git.netent.com/scm/ngp/jenkins-workflow-libs.git </url> <credentialsId> myCredentialsId </credentialsId> </hudson.plugins.git.UserRemoteConfig> </userRemoteConfigs> <branches> <hudson.plugins.git.BranchSpec> <name> refs/heads/${library.netentNGPCoreLib.version} </name> ... and run 'Reload Configuration from Disk', but I still get error: Loading library netentNGPCoreLib@master > /opt/rh/git19/root/usr/bin/git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > /opt/rh/git19/root/usr/bin/git config remote.origin.url https://git.netent.com/scm/ngp/jenkins-workflow-libs.git # timeout=10 Fetching upstream changes from https://git.netent.com/scm/ngp/jenkins-workflow-libs.git > /opt/rh/git19/root/usr/bin/git --version # timeout=10 > /opt/rh/git19/root/usr/bin/git fetch --tags --progress https://git.netent.com/scm/ngp/jenkins-workflow-libs.git +refs/heads/*:refs/remotes/origin/* ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from https://git.netent.com/scm/ngp/jenkins-workflow-libs.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:797) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1051) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1082) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.libs.SCMSourceRetriever.doRetrieve(SCMSourceRetriever.java:102) at org.jenkinsci.plugins.workflow.libs.SCMRetriever.retrieve(SCMRetriever.java:58) at org.jenkinsci.plugins.workflow.libs.LibraryAdder.retrieve(LibraryAdder.java:150) at org.jenkinsci.plugins.workflow.libs.LibraryAdder.add(LibraryAdder.java:131) at org.jenkinsci.plugins.workflow.libs.LibraryDecorator$1.call(LibraryDecorator.java:99) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:970) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:548) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:526) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:503) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:302) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:281) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731) at groovy.lang.GroovyShell.parse(GroovyShell.java:743) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410) Caused by: hudson.plugins.git.GitException: Command "/opt/rh/git19/root/usr/bin/git fetch --tags --progress https://git.netent.com/scm/ngp/jenkins-workflow-libs.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: fatal: Authentication failed for 'https://git.netent.com/scm/ngp/jenkins-workflow-libs.git/' at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1752) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1495) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:64) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:315) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:795) ... 22 more ERROR: null org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: Loading libraries failed 1 error at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:302) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:997) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:548) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:526) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:503) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:302) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:281) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731) at groovy.lang.GroovyShell.parse(GroovyShell.java:743) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410) Finished: FAILURE The credentials are used in other places so they should work. Noteworthy may be that when I go to global config page, I do not see the credentials in the dropdown.
            henok Hendrik Brinkmann added a comment - - edited

            Your git-url starts with https://. Is your credential a username with password or a private ssh-key? If the latter applied, I would expect an url that starts with ssh://

             <url>https://git.netent.com/scm/ngp/jenkins-workflow-libs.git</url>
            
            henok Hendrik Brinkmann added a comment - - edited Your git-url starts with https:// . Is your credential a username with password or a private ssh-key? If the latter applied, I would expect an url that starts with ssh:// <url> https://git.netent.com/scm/ngp/jenkins-workflow-libs.git </url>
            pianoroy Roy Tinker added a comment - Related (or redundant) issue: https://issues.jenkins-ci.org/browse/JENKINS-38424
            marcus_phi Marcus Philip added a comment -

            henok I use http protocol indeed, so jglick the question is still open: Did you actually get that workaround to work. I cannot.

            marcus_phi Marcus Philip added a comment - henok I use http protocol indeed, so jglick the question is still open: Did you actually get that workaround to work. I cannot.
            dgomez Dayton Gomez added a comment -

            I've also tried the workaround using SSH, and it didn't work either. Simply gave me an auth error and bailed out.

            dgomez Dayton Gomez added a comment - I've also tried the workaround using SSH, and it didn't work either. Simply gave me an auth error and bailed out.
            glance Anton Lundin added a comment -

            I'm running into this issue to. I worked around it by modifying the html of the configure page in devtools, adding the credeltials to the dropdown and it now works.

            I use Legacy Subversion over http.

            glance Anton Lundin added a comment - I'm running into this issue to. I worked around it by modifying the html of the configure page in devtools, adding the credeltials to the dropdown and it now works. I use Legacy Subversion over http.
            pianoroy Roy Tinker added a comment -

            The workaround seemed to work, but then I got E200015: ISVNAuthentication provider did not provide credentials.

            I decided to dodge global pipeline libraries altogether and just checkout from SVN and load the pipeline library file directly. Here's what that looks like: https://gist.github.com/RoyTinker/69d0f1b962cb91336db4d2180934af3e

            pianoroy Roy Tinker added a comment - The workaround seemed to work, but then I got E200015: ISVNAuthentication provider did not provide credentials. I decided to dodge global pipeline libraries altogether and just checkout from SVN and load the pipeline library file directly. Here's what that looks like: https://gist.github.com/RoyTinker/69d0f1b962cb91336db4d2180934af3e
            alanranciato Alan Ranciato added a comment -

            glance - Can you provide more details of your workaround? I like the way it sounds.

            I am using the Multibranch pipeline plugin so I don't have the option of getting around the sandbox so my only option to perform anything somewhat complex (Artifactory Maven builds for example) is the global pipeline library so I have something trusted.

            The lack of credentials in stopping me from moving forward.

            alanranciato Alan Ranciato added a comment - glance - Can you provide more details of your workaround? I like the way it sounds. I am using the Multibranch pipeline plugin so I don't have the option of getting around the sandbox so my only option to perform anything somewhat complex (Artifactory Maven builds for example) is the global pipeline library so I have something trusted. The lack of credentials in stopping me from moving forward.
            glance Anton Lundin added a comment -

            Edit the select drop down and just add the <option> inside the <select> containing the right credentials. You can copy the options tag from a working svn configuration page.

            glance Anton Lundin added a comment - Edit the select drop down and just add the <option> inside the <select> containing the right credentials. You can copy the options tag from a working svn configuration page.
            alanranciato Alan Ranciato added a comment -

            glance sorry for my ignorance - where Are the html files located that you're modifying? I assume you are doing this post - compile on your running version?

            Thx

            alanranciato Alan Ranciato added a comment - glance sorry for my ignorance - where Are the html files located that you're modifying? I assume you are doing this post - compile on your running version? Thx
            glance Anton Lundin added a comment -

            I used devtoos in chrome to change the page. If you don't know how to do that this ain't the support forum for that.

            glance Anton Lundin added a comment - I used devtoos in chrome to change the page. If you don't know how to do that this ain't the support forum for that.
            alanranciato Alan Ranciato added a comment -

            glance - THANK YOU! I didn't catch the answer b/c I didn't think there was any way that was the actual fix... I feel dirty after doing it, but your fix works and gave me what I needed to move forward. Someday, maybe, the PRs will get accepted and we won't have to do this...

            Until then, THANK YOU for your assistance!

            alanranciato Alan Ranciato added a comment - glance - THANK YOU! I didn't catch the answer b/c I didn't think there was any way that was the actual fix... I feel dirty after doing it, but your fix works and gave me what I needed to move forward. Someday, maybe, the PRs will get accepted and we won't have to do this... Until then, THANK YOU for your assistance!
            lharris Lane Harris added a comment -

            bwalding, were you ever able to get the version substitution working?

            We are seeing the same behavior. Everything works well with hardcoded versions, but using an overridable version is a no go:

            Loading library pipeline-common@jira/PIPELINE-6
             > git rev-parse --is-inside-work-tree # timeout=10
            Fetching changes from the remote Git repository
             > git config remote.origin.url git@code.corp.indeed.com:delivery/pipeline-common.git # timeout=10
            Fetching upstream changes from git@code.corp.indeed.com:delivery/pipeline-common.git
             > git --version # timeout=10
            using GIT_SSH to set credentials 
             > git fetch --tags --progress git@code.corp.indeed.com:delivery/pipeline-common.git +refs/heads/*:refs/remotes/origin/*
             > git rev-parse refs/remotes/origin/${library.pipeline-common.version}^{commit} # timeout=10
             > git rev-parse refs/remotes/origin/refs/heads/${library.pipeline-common.version}^{commit} # timeout=10
             > git rev-parse refs/heads/${library.pipeline-common.version}^{commit} # timeout=10
            ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
            
            <?xml version='1.0' encoding='UTF-8'?>
            <org.jenkinsci.plugins.workflow.libs.GlobalLibraries plugin="workflow-cps-global-lib@2.4">
              <libraries>
                <org.jenkinsci.plugins.workflow.libs.LibraryConfiguration>
                  <name>pipeline-common</name>
                  <retriever class="org.jenkinsci.plugins.workflow.libs.SCMRetriever">
                    <scm class="hudson.plugins.git.GitSCM" plugin="git@3.0.0">
                      <configVersion>2</configVersion>
                      <userRemoteConfigs>
                        <hudson.plugins.git.UserRemoteConfig>
                          <url>git@code.corp.indeed.com:delivery/pipeline-common.git</url>
                          <credentialsId>lharris-dev</credentialsId>
                        </hudson.plugins.git.UserRemoteConfig>
                      </userRemoteConfigs>
                      <branches>
                        <hudson.plugins.git.BranchSpec>
                          <name>refs/heads/${library.pipeline-common.version}</name>
                        </hudson.plugins.git.BranchSpec>
                      </branches>
                      <doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations>
                      <submoduleCfg class="list"/>
                      <extensions/>
                    </scm>
                  </retriever>
                  <implicit>false</implicit>
                  <allowVersionOverride>true</allowVersionOverride>
                </org.jenkinsci.plugins.workflow.libs.LibraryConfiguration>
              </libraries>
            </org.jenkinsci.plugins.workflow.libs.GlobalLibraries>
            
            Git client plugin (git-client): 2.0.0
            Git plugin (git): 3.0.0
            Pipeline: API (workflow-api): 2.3
            Pipeline: Basic Steps (workflow-basic-steps): 2.1
            Pipeline: Build Step (pipeline-build-step): 2.2
            Pipeline Graph Analysis Plugin (pipeline-graph-analysis): 1.1
            Pipeline: Groovy (workflow-cps): 2.15
            Pipeline: Input Step (pipeline-input-step): 2.1
            Pipeline: Job (workflow-job): 2.6
            Pipeline: Model Definition (pipeline-model-definition): 0.2
            Pipeline: Multibranch (workflow-multibranch): 2.8
            Pipeline: Nodes and Processes (workflow-durable-task-step): 2.4
            Pipeline: REST API Plugin (pipeline-rest-api): 2.0
            Pipeline: SCM Step (workflow-scm-step): 2.2
            Pipeline: Shared Groovy Libraries (workflow-cps-global-lib): 2.4
            Pipeline: Stage Step (pipeline-stage-step): 2.2
            Pipeline: Stage View Plugin (pipeline-stage-view): 2.0
            Pipeline: Step API (workflow-step-api): 2.3
            Pipeline: Supporting APIs (workflow-support): 2.2
            Pipeline (workflow-aggregator): 2.3
            SCM API Plugin (scm-api): 1.3
            
            lharris Lane Harris added a comment - bwalding , were you ever able to get the version substitution working? We are seeing the same behavior. Everything works well with hardcoded versions, but using an overridable version is a no go: Loading library pipeline-common@jira/PIPELINE-6 > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url git@code.corp.indeed.com:delivery/pipeline-common.git # timeout=10 Fetching upstream changes from git@code.corp.indeed.com:delivery/pipeline-common.git > git --version # timeout=10 using GIT_SSH to set credentials > git fetch --tags --progress git@code.corp.indeed.com:delivery/pipeline-common.git +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/${library.pipeline-common.version}^{commit} # timeout=10 > git rev-parse refs/remotes/origin/refs/heads/${library.pipeline-common.version}^{commit} # timeout=10 > git rev-parse refs/heads/${library.pipeline-common.version}^{commit} # timeout=10 ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job. <?xml version='1.0' encoding='UTF-8'?> <org.jenkinsci.plugins.workflow.libs.GlobalLibraries plugin="workflow-cps-global-lib@2.4"> <libraries> <org.jenkinsci.plugins.workflow.libs.LibraryConfiguration> <name>pipeline-common</name> <retriever class="org.jenkinsci.plugins.workflow.libs.SCMRetriever"> <scm class="hudson.plugins.git.GitSCM" plugin="git@3.0.0"> <configVersion>2</configVersion> <userRemoteConfigs> <hudson.plugins.git.UserRemoteConfig> <url>git@code.corp.indeed.com:delivery/pipeline-common.git</url> <credentialsId>lharris-dev</credentialsId> </hudson.plugins.git.UserRemoteConfig> </userRemoteConfigs> <branches> <hudson.plugins.git.BranchSpec> <name>refs/heads/${library.pipeline-common.version}</name> </hudson.plugins.git.BranchSpec> </branches> <doGenerateSubmoduleConfigurations>false</doGenerateSubmoduleConfigurations> <submoduleCfg class="list"/> <extensions/> </scm> </retriever> <implicit>false</implicit> <allowVersionOverride>true</allowVersionOverride> </org.jenkinsci.plugins.workflow.libs.LibraryConfiguration> </libraries> </org.jenkinsci.plugins.workflow.libs.GlobalLibraries> Git client plugin (git-client): 2.0.0 Git plugin (git): 3.0.0 Pipeline: API (workflow-api): 2.3 Pipeline: Basic Steps (workflow-basic-steps): 2.1 Pipeline: Build Step (pipeline-build-step): 2.2 Pipeline Graph Analysis Plugin (pipeline-graph-analysis): 1.1 Pipeline: Groovy (workflow-cps): 2.15 Pipeline: Input Step (pipeline-input-step): 2.1 Pipeline: Job (workflow-job): 2.6 Pipeline: Model Definition (pipeline-model-definition): 0.2 Pipeline: Multibranch (workflow-multibranch): 2.8 Pipeline: Nodes and Processes (workflow-durable-task-step): 2.4 Pipeline: REST API Plugin (pipeline-rest-api): 2.0 Pipeline: SCM Step (workflow-scm-step): 2.2 Pipeline: Shared Groovy Libraries (workflow-cps-global-lib): 2.4 Pipeline: Stage Step (pipeline-stage-step): 2.2 Pipeline: Stage View Plugin (pipeline-stage-view): 2.0 Pipeline: Step API (workflow-step-api): 2.3 Pipeline: Supporting APIs (workflow-support): 2.2 Pipeline (workflow-aggregator): 2.3 SCM API Plugin (scm-api): 1.3

            Code changed in jenkins
            User: Jesse Glick
            Path:
            pom.xml
            src/main/java/hudson/scm/SubversionSCM.java
            src/main/java/hudson/scm/SubversionTagAction.java
            src/main/java/hudson/scm/browsers/Sventon.java
            src/main/java/hudson/scm/browsers/Sventon2.java
            src/main/java/jenkins/scm/impl/subversion/SubversionSCMSource.java
            http://jenkins-ci.org/commit/subversion-plugin/1355c64e36933049fcb3c2f50cc3eaf189cef241
            Log:
            JENKINS-38048 Permits credentialsId dropdowns to be used from a global configuration screen.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: pom.xml src/main/java/hudson/scm/SubversionSCM.java src/main/java/hudson/scm/SubversionTagAction.java src/main/java/hudson/scm/browsers/Sventon.java src/main/java/hudson/scm/browsers/Sventon2.java src/main/java/jenkins/scm/impl/subversion/SubversionSCMSource.java http://jenkins-ci.org/commit/subversion-plugin/1355c64e36933049fcb3c2f50cc3eaf189cef241 Log: JENKINS-38048 Permits credentialsId dropdowns to be used from a global configuration screen.

            Code changed in jenkins
            User: Manuel Recena
            Path:
            pom.xml
            src/main/java/hudson/scm/SubversionSCM.java
            src/main/java/hudson/scm/SubversionTagAction.java
            src/main/java/hudson/scm/browsers/Sventon.java
            src/main/java/hudson/scm/browsers/Sventon2.java
            src/main/java/jenkins/scm/impl/subversion/SubversionSCMSource.java
            http://jenkins-ci.org/commit/subversion-plugin/ca23e9fa4b4f3bdac4112f1157cfc9efe303d3f7
            Log:
            Merge pull request #169 from jglick/global-credentialsId-JENKINS-38048

            JENKINS-38048 Permit credentialsId dropdowns to be used from a global configuration screen

            Compare: https://github.com/jenkinsci/subversion-plugin/compare/3159d9a64e23...ca23e9fa4b4f

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Manuel Recena Path: pom.xml src/main/java/hudson/scm/SubversionSCM.java src/main/java/hudson/scm/SubversionTagAction.java src/main/java/hudson/scm/browsers/Sventon.java src/main/java/hudson/scm/browsers/Sventon2.java src/main/java/jenkins/scm/impl/subversion/SubversionSCMSource.java http://jenkins-ci.org/commit/subversion-plugin/ca23e9fa4b4f3bdac4112f1157cfc9efe303d3f7 Log: Merge pull request #169 from jglick/global-credentialsId- JENKINS-38048 JENKINS-38048 Permit credentialsId dropdowns to be used from a global configuration screen Compare: https://github.com/jenkinsci/subversion-plugin/compare/3159d9a64e23...ca23e9fa4b4f
            mkobit Mike Kobit added a comment - - edited

            Git is still waiting on https://github.com/jenkinsci/git-plugin/pull/437, really looking forward to not having to use Chrome Editor tools to use this feature!

            mkobit Mike Kobit added a comment - - edited Git is still waiting on https://github.com/jenkinsci/git-plugin/pull/437 , really looking forward to not having to use Chrome Editor tools to use this feature!
            jglick Jesse Glick added a comment -

            For Subversion users this is now fixed in 2.7.1.

            For Git, ping markewaite.

            jglick Jesse Glick added a comment - For Subversion users this is now fixed in 2.7.1. For Git, ping markewaite .
            jglick Jesse Glick added a comment -

            Mercurial needs some more work, which I have lumped into JENKINS-35535.

            jglick Jesse Glick added a comment - Mercurial needs some more work, which I have lumped into JENKINS-35535 .
            markewaite Mark Waite added a comment - - edited

            I've merged PR433 and PR437 to an evaluation branch in my repository and am running various tests now to confirm it behaves as expected.

            I'm able to confirm the bug exists (with a Jenkins 2.19.1 LTS docker image, downloading the latest plugins, including git plugin 3.0.0 and git client plugin 2.0.0).

            When I built a version of git plugin which merges the master branch, PR433, and PR437, the credentials drop down still does not populate. The commit history for that shows the change which jglick referenced, but does not show the global credentials drop down.

            I'll need to do some further debugging to understand what's happening.

            It seems that the credentials plugin includeMatchingAs() method may not accept a null project, yet in a global context, the project will be null. Is there an alternative to includeMatchingAs() which does not require a project for context?

            markewaite Mark Waite added a comment - - edited I've merged PR433 and PR437 to an evaluation branch in my repository and am running various tests now to confirm it behaves as expected. I'm able to confirm the bug exists (with a Jenkins 2.19.1 LTS docker image , downloading the latest plugins, including git plugin 3.0.0 and git client plugin 2.0.0). When I built a version of git plugin which merges the master branch, PR433, and PR437, the credentials drop down still does not populate. The commit history for that shows the change which jglick referenced, but does not show the global credentials drop down. I'll need to do some further debugging to understand what's happening. It seems that the credentials plugin includeMatchingAs() method may not accept a null project, yet in a global context, the project will be null. Is there an alternative to includeMatchingAs() which does not require a project for context?
            markewaite Mark Waite added a comment - - edited

            I pushed a change onto my evaluation branch which creates a fake project if the project is null. It seems to be well-behaved in the case I tested. However, I suspect that is not the right way to solve the problem.

            jglick, can you provide suggestions of a better way to handle that case?

            Refer to the specific diffs for my change.

            The findbugs analysis also adds a new warning about project potentially being null when the isMatchingAs signature declares it must be non-null (same pattern as in UserRemoteConfig, just needs a different non-null object type). It says:

            Null passed for non-null parameter of com.cloudbees.plugins.credentials.common.AbstractIdCredentialsListBoxModel.includeMatchingAs(Authentication, Item, Class, List, CredentialsMatcher) in jenkins.plugins.git.GitSCMSource$DescriptorImpl.doFillCredentialsIdItems(SCMSourceOwner, String, String) [jenkins.plugins.git.GitSCMSource$DescriptorImpl, jenkins.plugins.git.GitSCMSource$DescriptorImpl] Method invoked at GitSCMSource.java:[line 201]Known null at GitSCMSource.java:[line 195]
            
            markewaite Mark Waite added a comment - - edited I pushed a change onto my evaluation branch which creates a fake project if the project is null. It seems to be well-behaved in the case I tested. However, I suspect that is not the right way to solve the problem. jglick , can you provide suggestions of a better way to handle that case? Refer to the specific diffs for my change. The findbugs analysis also adds a new warning about project potentially being null when the isMatchingAs signature declares it must be non-null (same pattern as in UserRemoteConfig, just needs a different non-null object type). It says: Null passed for non- null parameter of com.cloudbees.plugins.credentials.common.AbstractIdCredentialsListBoxModel.includeMatchingAs(Authentication, Item, Class , List, CredentialsMatcher) in jenkins.plugins.git.GitSCMSource$DescriptorImpl.doFillCredentialsIdItems(SCMSourceOwner, String , String ) [jenkins.plugins.git.GitSCMSource$DescriptorImpl, jenkins.plugins.git.GitSCMSource$DescriptorImpl] Method invoked at GitSCMSource.java:[line 201]Known null at GitSCMSource.java:[line 195]
            jglick Jesse Glick added a comment -

            Creating a fake project is definitely not right.

            Yes I know the declared signature says @Nonnull; refer to credentials PR 68 for why it should be OK anyway.

            The change worked fine when I developed it, so something must have broken since then. Apparently I will need to revisit the PR. Probably I can add functional tests for it—last I recall there were none is this area.

            jglick Jesse Glick added a comment - Creating a fake project is definitely not right. Yes I know the declared signature says @Nonnull ; refer to credentials PR 68 for why it should be OK anyway. The change worked fine when I developed it, so something must have broken since then. Apparently I will need to revisit the PR. Probably I can add functional tests for it—last I recall there were none is this area.

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/java/com/cloudbees/plugins/credentials/common/AbstractIdCredentialsListBoxModel.java
            http://jenkins-ci.org/commit/credentials-plugin/65e143c42ee9ba7de274482dbf4751e37de8d93d
            Log:
            JENKINS-38048 Relax nullability on Item/ItemGroup context parameters.
            The underlying checks already handle null values.
            Makes it easier to provide credentials dropdowns in global configuration.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/com/cloudbees/plugins/credentials/common/AbstractIdCredentialsListBoxModel.java http://jenkins-ci.org/commit/credentials-plugin/65e143c42ee9ba7de274482dbf4751e37de8d93d Log: JENKINS-38048 Relax nullability on Item/ItemGroup context parameters. The underlying checks already handle null values. Makes it easier to provide credentials dropdowns in global configuration.

            Code changed in jenkins
            User: Stephen Connolly
            Path:
            src/main/java/com/cloudbees/plugins/credentials/common/AbstractIdCredentialsListBoxModel.java
            http://jenkins-ci.org/commit/credentials-plugin/408765b9ad75caf79f8eb03d0b2a524534ed0b64
            Log:
            Merge pull request #68 from jglick/global-credentialsId-JENKINS-38048

            JENKINS-38048 Relax nullability on Item/ItemGroup context parameters

            Compare: https://github.com/jenkinsci/credentials-plugin/compare/abebf76a8f57...408765b9ad75

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: src/main/java/com/cloudbees/plugins/credentials/common/AbstractIdCredentialsListBoxModel.java http://jenkins-ci.org/commit/credentials-plugin/408765b9ad75caf79f8eb03d0b2a524534ed0b64 Log: Merge pull request #68 from jglick/global-credentialsId- JENKINS-38048 JENKINS-38048 Relax nullability on Item/ItemGroup context parameters Compare: https://github.com/jenkinsci/credentials-plugin/compare/abebf76a8f57...408765b9ad75

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/main/java/hudson/plugins/git/UserRemoteConfig.java
            src/main/java/jenkins/plugins/git/GitSCMSource.java
            http://jenkins-ci.org/commit/git-plugin/b52b095c8310c607d28120b3a20137eacc58a64c
            Log:
            JENKINS-38048 Permits credentialsId dropdowns to be used from a global configuration screen.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/main/java/hudson/plugins/git/UserRemoteConfig.java src/main/java/jenkins/plugins/git/GitSCMSource.java http://jenkins-ci.org/commit/git-plugin/b52b095c8310c607d28120b3a20137eacc58a64c Log: JENKINS-38048 Permits credentialsId dropdowns to be used from a global configuration screen.

            Code changed in jenkins
            User: Jesse Glick
            Path:
            src/test/java/hudson/plugins/git/UserRemoteConfigTest.java
            http://jenkins-ci.org/commit/git-plugin/bf0465f7a8d3f1811c6b458fe1c8f868875b5a6f
            Log:
            JENKINS-38048 Proving fix in functional test.

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: src/test/java/hudson/plugins/git/UserRemoteConfigTest.java http://jenkins-ci.org/commit/git-plugin/bf0465f7a8d3f1811c6b458fe1c8f868875b5a6f Log: JENKINS-38048 Proving fix in functional test.
            mkobit Mike Kobit added a comment -

            markewaite - do you need any assistance in testing/releasing this change?

            mkobit Mike Kobit added a comment - markewaite - do you need any assistance in testing/releasing this change?
            markewaite Mark Waite added a comment -

            No, I think it has passed enough of my tests to be released. It should be released before the end of the week.

            markewaite Mark Waite added a comment - No, I think it has passed enough of my tests to be released. It should be released before the end of the week.
            rgoomar Rishi Goomar added a comment -

            markewaite Any updates on the release for this bug?

            rgoomar Rishi Goomar added a comment - markewaite Any updates on the release for this bug?
            hamiltb Bill Hamilton added a comment -

            I just installed:
            credentials 2.19
            git 3.0
            subversion 2.7.0
            workflow-cps-global-lib 2.4

            restarted....and the dropdown is still empty (only contains none).
            Is this really fixed?

            hamiltb Bill Hamilton added a comment - I just installed: credentials 2.19 git 3.0 subversion 2.7.0 workflow-cps-global-lib 2.4 restarted....and the dropdown is still empty (only contains none ). Is this really fixed?
            markewaite Mark Waite added a comment -

            Fixed but not yet released. A pre-release build is available if you need it faster.

            markewaite Mark Waite added a comment - Fixed but not yet released. A pre-release build is available if you need it faster.
            hamiltb Bill Hamilton added a comment -

            Hi Mark,
            CloudBees support showed me how I can take an issue that is marked as fixed (like this one), and go into each of the PRs, and then see what release label contains that fix. So this led me to determining that the above versions of plugins would comprise the fix. And they are available, so I installed them, but it didnt fix it.
            So was my process of tracking plugin versions incorrect?
            Thanks.

            hamiltb Bill Hamilton added a comment - Hi Mark, CloudBees support showed me how I can take an issue that is marked as fixed (like this one), and go into each of the PRs, and then see what release label contains that fix. So this led me to determining that the above versions of plugins would comprise the fix. And they are available, so I installed them, but it didnt fix it. So was my process of tracking plugin versions incorrect? Thanks.
            markewaite Mark Waite added a comment -

            No, your process of tracking plugins is reasonable, but didn't cover the scenario which the git plugin is currently managing.

            The git plugin delivered a major release (3.0.0) which added submodule authentication. However, the changes needed for submodule authentication were broad enough that they broke compatibility with authentication at some git plugin installations. There are several bugs authentication bugs which have been reported that indicate the changes introduced incompatibilities.

            This change was applied (and released) in git plugin 2.6.1 in order to retain compatibility with the git plugin 2.x line. It will also be released in the near future as a git plugin 3.0.1.

            If you need it immediately in released form, and don't need the features added in git plugin 3.0.0, you can download and install 2.6.1 and use it. Otherwise, you can wait a few days and I'll have released the git plugin 3.0.1 version which also includes the fix.

            markewaite Mark Waite added a comment - No, your process of tracking plugins is reasonable, but didn't cover the scenario which the git plugin is currently managing. The git plugin delivered a major release (3.0.0) which added submodule authentication. However, the changes needed for submodule authentication were broad enough that they broke compatibility with authentication at some git plugin installations. There are several bugs authentication bugs which have been reported that indicate the changes introduced incompatibilities. This change was applied (and released) in git plugin 2.6.1 in order to retain compatibility with the git plugin 2.x line. It will also be released in the near future as a git plugin 3.0.1. If you need it immediately in released form, and don't need the features added in git plugin 3.0.0, you can download and install 2.6.1 and use it. Otherwise, you can wait a few days and I'll have released the git plugin 3.0.1 version which also includes the fix.
            hamiltb Bill Hamilton added a comment -

            Mark,
            Thanks, I will wait for git plugin 3.0.1

            hamiltb Bill Hamilton added a comment - Mark, Thanks, I will wait for git plugin 3.0.1
            markewaite Mark Waite added a comment -

            Released in git plugin 3.0.1, 18 Nov 2016

            markewaite Mark Waite added a comment - Released in git plugin 3.0.1, 18 Nov 2016
            hamiltb Bill Hamilton added a comment -

            Mark,
            I just upgraded to Jenkins Git 3.01 (which brought with it Credentials 2.1.9, Jenkins Mailer 1.18, and Jenkins Git client 2.1.0) and a simple "checkout scm" failed with:

            (obfuscated with "-----")
            Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://-------/hamiltb/svc-foobar.git +refs/heads/:refs/remotes/origin/" returned status code 128:
            stderr: fatal: cannot exec '/tmp/pass7365890844204257456.sh': Permission denied
            fatal: could not read Username for 'https://-------------': No such device or address

            hamiltb Bill Hamilton added a comment - Mark, I just upgraded to Jenkins Git 3.01 (which brought with it Credentials 2.1.9, Jenkins Mailer 1.18, and Jenkins Git client 2.1.0) and a simple "checkout scm" failed with: (obfuscated with "-----") Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --progress https://-------/hamiltb/svc-foobar.git +refs/heads/ :refs/remotes/origin/ " returned status code 128: stderr: fatal: cannot exec '/tmp/pass7365890844204257456.sh': Permission denied fatal: could not read Username for 'https://-------------': No such device or address
            markewaite Mark Waite added a comment -

            The message:

            stderr: fatal: cannot exec '/tmp/pass7365890844204257456.sh': Permission denied

            indicates that a file that was written to the /tmp/ directory on the agent that was trying to do the checkout was not made executable. Some possible reasons for it not being made executable might include:

            • Wrong permissions on the /tmp/ directory on the agent (refuses to allow an executable script to run from /tmp)
            • Out of disc space in the /tmp/ directory on the agent (could not write the script to /tmp/)
            • Other file system related oddities on that slave agent

            Since the message:

            fatal: could not read Username for 'https://-------------': No such device or address

            came later in the log, I assume it is a symptom of the earlier message, not the specific message.

            markewaite Mark Waite added a comment - The message: stderr: fatal: cannot exec '/tmp/pass7365890844204257456.sh': Permission denied indicates that a file that was written to the /tmp/ directory on the agent that was trying to do the checkout was not made executable. Some possible reasons for it not being made executable might include: Wrong permissions on the /tmp/ directory on the agent (refuses to allow an executable script to run from /tmp) Out of disc space in the /tmp/ directory on the agent (could not write the script to /tmp/) Other file system related oddities on that slave agent Since the message: fatal: could not read Username for 'https://-------------': No such device or address came later in the log, I assume it is a symptom of the earlier message, not the specific message.
            jglick Jesse Glick added a comment -

            hamiltb better filed & discussed separately, especially if it is reproducible. Off topic in this issue.

            jglick Jesse Glick added a comment - hamiltb better filed & discussed separately, especially if it is reproducible. Off topic in this issue.

            People

              jglick Jesse Glick
              bwalding Ben Walding
              Votes:
              17 Vote for this issue
              Watchers:
              31 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: