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.

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

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

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.

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

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) ?

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.

I think JENKINS-38272 is a duplicate

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.

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>

Related (or redundant) issue: https://issues.jenkins-ci.org/browse/JENKINS-38424

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

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

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.

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

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.

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 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

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 - 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!

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.

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

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!

For Subversion users this is now fixed in 2.7.1.

For Git, ping markewaite.

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

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?

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]

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.

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.

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.

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

markewaite Any updates on the release for this bug?

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?

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

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.

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.

Mark,
Thanks, I will wait for git plugin 3.0.1

Released in git plugin 3.0.1, 18 Nov 2016

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

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.

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