[JIRA] (JENKINS-38048) Credentials dropdowns empty when configuring external libraries at the global level

55 views
Skip to first unread message

jglick@cloudbees.com (JIRA)

unread,
Sep 8, 2016, 10:58:02 AM9/8/16
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
 
Jenkins / Bug JENKINS-38048
Credentials dropdowns empty when configuring external libraries at the global level
Change By: Jesse Glick
Summary: credentials id dropdown not populated Credentials dropdowns empty when configuring external libraries at the global level
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

jglick@cloudbees.com (JIRA)

unread,
Sep 8, 2016, 10:58:02 AM9/8/16
to jenkinsc...@googlegroups.com
Jesse Glick updated an issue
Change By: Jesse Glick
Priority: Minor Major

bwalding@cloudbees.com (JIRA)

unread,
Sep 8, 2016, 8:14:02 PM9/8/16
to jenkinsc...@googlegroups.com
Ben Walding commented on Bug JENKINS-38048
 
Re: Credentials dropdowns empty when configuring external libraries at the global level

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.

gunter@grodotzki.co.za (JIRA)

unread,
Sep 9, 2016, 10:52:01 AM9/9/16
to jenkinsc...@googlegroups.com

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

jglick@cloudbees.com (JIRA)

unread,
Sep 13, 2016, 10:52:03 AM9/13/16
to jenkinsc...@googlegroups.com

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.a.philip@gmail.com (JIRA)

unread,
Sep 19, 2016, 3:53:05 AM9/19/16
to jenkinsc...@googlegroups.com

I think JENKINS-38272 is a duplicate

marcus.a.philip@gmail.com (JIRA)

unread,
Sep 19, 2016, 4:30:04 AM9/19/16
to jenkinsc...@googlegroups.com

Jesse Glick 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="g...@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.

hendrik@brinkmann.one (JIRA)

unread,
Sep 19, 2016, 8:51:05 AM9/19/16
to jenkinsc...@googlegroups.com

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

hendrik@brinkmann.one (JIRA)

unread,
Sep 19, 2016, 8:51:05 AM9/19/16
to jenkinsc...@googlegroups.com
Hendrik Brinkmann edited a comment on Bug JENKINS-38048
Your Git git - Url 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://}}

{code:xml}
<url>https://git.netent.com/scm/ngp/jenkins-workflow-libs.git</url>
{code}

hendrik@brinkmann.one (JIRA)

unread,
Sep 19, 2016, 8:52:02 AM9/19/16
to jenkinsc...@googlegroups.com
Hendrik Brinkmann edited a comment on Bug JENKINS-38048
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://}}

roytinker@gmail.com (JIRA)

unread,
Sep 23, 2016, 12:44:02 PM9/23/16
to jenkinsc...@googlegroups.com

marcus.a.philip@gmail.com (JIRA)

unread,
Sep 28, 2016, 8:11:04 AM9/28/16
to jenkinsc...@googlegroups.com

Hendrik Brinkmann I use http protocol indeed, so Jesse Glick the question is still open: Did you actually get that workaround to work. I cannot.

dgomez@absolute.com (JIRA)

unread,
Sep 28, 2016, 10:52:04 AM9/28/16
to jenkinsc...@googlegroups.com

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

glance+jenkins@acc.umu.se (JIRA)

unread,
Oct 3, 2016, 2:57:03 AM10/3/16
to jenkinsc...@googlegroups.com

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.

roytinker@gmail.com (JIRA)

unread,
Oct 3, 2016, 5:24:01 PM10/3/16
to jenkinsc...@googlegroups.com

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@gmail.com (JIRA)

unread,
Oct 5, 2016, 9:37:04 PM10/5/16
to jenkinsc...@googlegroups.com

Anton Lundin - 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+jenkins@acc.umu.se (JIRA)

unread,
Oct 6, 2016, 4:06:02 AM10/6/16
to jenkinsc...@googlegroups.com

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@gmail.com (JIRA)

unread,
Oct 6, 2016, 8:25:02 AM10/6/16
to jenkinsc...@googlegroups.com

Anton Lundin 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+jenkins@acc.umu.se (JIRA)

unread,
Oct 6, 2016, 11:22:02 AM10/6/16
to jenkinsc...@googlegroups.com

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@gmail.com (JIRA)

unread,
Oct 6, 2016, 8:20:03 PM10/6/16
to jenkinsc...@googlegroups.com

Anton Lundin - 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@indeed.com (JIRA)

unread,
Oct 14, 2016, 8:39:06 PM10/14/16
to jenkinsc...@googlegroups.com

Ben Walding, 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 g...@code.corp.indeed.com:delivery/pipeline-common.git # timeout=10
Fetching upstream changes from g...@code.corp.indeed.com:delivery/pipeline-common.git
 > git --version # timeout=10
using GIT_SSH to set credentials 
 > git fetch --tags --progress g...@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="g...@3.0.0">
          <configVersion>2</configVersion>
          <userRemoteConfigs>
            <hudson.plugins.git.UserRemoteConfig>
              <url>g...@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

scm_issue_link@java.net (JIRA)

unread,
Oct 18, 2016, 11:55:05 AM10/18/16
to jenkinsc...@googlegroups.com

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@java.net (JIRA)

unread,
Oct 18, 2016, 11:55:06 AM10/18/16
to jenkinsc...@googlegroups.com

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.

mkobit@gmail.com (JIRA)

unread,
Oct 18, 2016, 3:12:02 PM10/18/16
to jenkinsc...@googlegroups.com

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@gmail.com (JIRA)

unread,
Oct 18, 2016, 3:12:06 PM10/18/16
to jenkinsc...@googlegroups.com
Mike Kobit edited a comment on Bug JENKINS-38048
Still 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@cloudbees.com (JIRA)

unread,
Oct 21, 2016, 9:41:08 AM10/21/16
to jenkinsc...@googlegroups.com

For Subversion users this is now fixed in 2.7.1.

For Git, ping Mark Waite.

jglick@cloudbees.com (JIRA)

unread,
Oct 21, 2016, 9:42:03 AM10/21/16
to jenkinsc...@googlegroups.com

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

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 23, 2016, 12:13:02 PM10/23/16
to jenkinsc...@googlegroups.com

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 hope to release a new version of the git plugin with those changes in a week or less.

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 23, 2016, 2:22:03 PM10/23/16
to jenkinsc...@googlegroups.com
Mark Waite updated an issue
 
Jenkins / Bug JENKINS-38048
Change By: Mark Waite
Attachment: empty-global-pipeline-credential-dropdown.png

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 23, 2016, 2:29:01 PM10/23/16
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-38048
 
Re: Credentials dropdowns empty when configuring external libraries at the global level
I've merged [PR433|https://github.com/jenkinsci/git-plugin/pull/433] and [PR437|https://github.com/jenkinsci/git-plugin/pull/433] to an [evaluation branch|https://github.com/MarkEWaite/git-plugin/tree/3.0.0-beta-PR433-PR437-single-revision-and-global-config-credentials-dropdown] in my repository and am running various tests now to confirm it behaves as expected.

  I hope 'm able to release confirm the bug exists (with a new [Jenkins 2.19.1 LTS docker image|https://github.com/MarkEWaite/docker/tree/f70ac08688d0761353430c08a7fafee176894e24], 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|https://github.com/MarkEWaite/git-plugin/commit/596907ef61ea3bfce24586ba72492cc6b3fb0c49] which merges the master branch, PR433, and PR437, the credentials drop down still does not populate.  The commit history for that shows the [change|https://github.com/MarkEWaite/ git - plugin with those changes in a week or less /commit/086896ab4e53e6a98986522d0ddbebf1ad0eaf91] 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.

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 23, 2016, 2:30:02 PM10/23/16
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-38048
I'm able to confirm the bug exists (with a [Jenkins 2.19.1 LTS docker image|https://github.com/MarkEWaite/docker/tree/f70ac08688d0761353430c08a7fafee176894e24], 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|https://github.com/MarkEWaite/git-plugin/commit/596907ef61ea3bfce24586ba72492cc6b3fb0c49] which merges the master branch, PR433, and PR437, the credentials drop down still does not populate.  The commit history for that shows the [change|https://github.com/MarkEWaite/git-plugin/commit/086896ab4e53e6a98986522d0ddbebf1ad0eaf91] 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.

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 23, 2016, 9:58:02 PM10/23/16
to jenkinsc...@googlegroups.com
I'll need to do some further debugging to understand what's happening.    !empty-global-pipeline-credential-dropdown.png|thumbnail!

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 23, 2016, 10:04:07 PM10/23/16
to jenkinsc...@googlegroups.com

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 23, 2016, 11:46:02 PM10/23/16
to jenkinsc...@googlegroups.com


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?

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 24, 2016, 12:15:01 AM10/24/16
to jenkinsc...@googlegroups.com

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.

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

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 24, 2016, 12:16:01 AM10/24/16
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-38048
I pushed a change onto my [evaluation branch|https://github.com/MarkEWaite/git-plugin/tree/3.0.0-beta-PR433-PR437-single-revision-and-global-config-credentials-dropdown] 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|https://github.com/MarkEWaite/git-plugin/commit/91887a000c0082ba7403804fc95cbaf4eebdadf0] for my change.

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 24, 2016, 7:58:03 AM10/24/16
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-38048
I pushed a change onto my [evaluation branch|https://github.com/MarkEWaite/git-plugin/tree/3.0.0-beta-PR433-PR437-single-revision-and-global-config-credentials-dropdown] 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|https://github.com/MarkEWaite/git-plugin/commit/91887a000c0082ba7403804fc95cbaf4eebdadf0] 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.  It says:
{code}
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]
{code}

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 24, 2016, 8:06:04 AM10/24/16
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-38048
I pushed a change onto my [evaluation branch|https://github.com/MarkEWaite/git-plugin/tree/3.0.0-beta-PR433-PR437-single-revision-and-global-config-credentials-dropdown] 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|https://github.com/MarkEWaite/git-plugin/commit/91887a000c0082ba7403804fc95cbaf4eebdadf0] 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:

{code}
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]
{code}

jglick@cloudbees.com (JIRA)

unread,
Oct 24, 2016, 10:17:03 AM10/24/16
to jenkinsc...@googlegroups.com

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.

scm_issue_link@java.net (JIRA)

unread,
Oct 28, 2016, 2:59:03 AM10/28/16
to jenkinsc...@googlegroups.com

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@java.net (JIRA)

unread,
Oct 28, 2016, 2:59:14 AM10/28/16
to jenkinsc...@googlegroups.com

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

scm_issue_link@java.net (JIRA)

unread,
Oct 29, 2016, 2:19:04 PM10/29/16
to jenkinsc...@googlegroups.com

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@java.net (JIRA)

unread,
Oct 29, 2016, 2:19:04 PM10/29/16
to jenkinsc...@googlegroups.com

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.

jglick@cloudbees.com (JIRA)

unread,
Oct 31, 2016, 9:59:03 AM10/31/16
to jenkinsc...@googlegroups.com
Change By: Jesse Glick
Status: In Review Resolved
Resolution: Fixed

mkobit@gmail.com (JIRA)

unread,
Nov 9, 2016, 4:12:02 PM11/9/16
to jenkinsc...@googlegroups.com
Mike Kobit commented on Bug JENKINS-38048
 
Re: Credentials dropdowns empty when configuring external libraries at the global level

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

mark.earl.waite@gmail.com (JIRA)

unread,
Nov 9, 2016, 8:46:01 PM11/9/16
to jenkinsc...@googlegroups.com

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

rishig92@gmail.com (JIRA)

unread,
Nov 18, 2016, 11:20:05 AM11/18/16
to jenkinsc...@googlegroups.com

Mark Waite Any updates on the release for this bug?

bill.hamilton@autodesk.com (JIRA)

unread,
Nov 18, 2016, 3:32:02 PM11/18/16
to jenkinsc...@googlegroups.com

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?

mark.earl.waite@gmail.com (JIRA)

unread,
Nov 18, 2016, 5:25:01 PM11/18/16
to jenkinsc...@googlegroups.com

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

bill.hamilton@autodesk.com (JIRA)

unread,
Nov 18, 2016, 5:32:02 PM11/18/16
to jenkinsc...@googlegroups.com

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.

mark.earl.waite@gmail.com (JIRA)

unread,
Nov 18, 2016, 6:29:04 PM11/18/16
to jenkinsc...@googlegroups.com

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.

bill.hamilton@autodesk.com (JIRA)

unread,
Nov 18, 2016, 9:02:03 PM11/18/16
to jenkinsc...@googlegroups.com

Mark,
Thanks, I will wait for git plugin 3.0.1

mark.earl.waite@gmail.com (JIRA)

unread,
Nov 19, 2016, 6:54:07 AM11/19/16
to jenkinsc...@googlegroups.com
Mark Waite closed an issue as Fixed
 

Released in git plugin 3.0.1, 18 Nov 2016
Change By: Mark Waite
Status: Resolved Closed

bill.hamilton@autodesk.com (JIRA)

unread,
Nov 21, 2016, 12:04:02 PM11/21/16
to jenkinsc...@googlegroups.com
 
Re: Credentials dropdowns empty when configuring external libraries at the global level

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

mark.earl.waite@gmail.com (JIRA)

unread,
Nov 21, 2016, 2:09:02 PM11/21/16
to jenkinsc...@googlegroups.com

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@cloudbees.com (JIRA)

unread,
Nov 23, 2016, 1:20:16 PM11/23/16
to jenkinsc...@googlegroups.com

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

mkobit@gmail.com (JIRA)

unread,
Mar 21, 2017, 4:21:06 PM3/21/17
to jenkinsc...@googlegroups.com

Has anybody seen this working with recent versions of pipeline plugins and Jenkins?
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

mkobit@gmail.com (JIRA)

unread,
Mar 21, 2017, 4:21:09 PM3/21/17
to jenkinsc...@googlegroups.com
Mike Kobit updated an issue
 
Change By: Mike Kobit
Comment:
Has anybody seen this working with recent versions of pipeline plugins and Jenkins?
Reply all
Reply to author
Forward
0 new messages