-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Windows Server 2012 R2 64 Bit
Java SE 1.8.0_144
Jenkins 2.60.2 (running as Windows service)
Pipeline: Shared Groovy Libraries 2.8
Credentials Plugin 2.1.14
I am trying to add a global shared library in the Jenkins configuration. The library is in a Git repository which is accessed via https with password authentication. I configured this library using the Modern SCM option.
I added the credentials with the name "Jenkins Credentials" in the global credentials store with "System" scope.
The global library configuration says "Currently maps to revision: <correct revision>" for the default version, which indicates that the configuration is correct.
When I try to use this library in a job, the message "using GIT_ASKPASS to set credentials Jenkins Credentials", however, authentication fails ("fatal: Authentication failed for 'https://[...]'" from git fetch).
When I set the credentials from "System" to "Global" scope, the job works as expected. However, with this configuration, everyone with permissions to create jobs can use these credentials in their job, which is not desired.
[JENKINS-45843] Unable to use system credentials for global pipeline library
Thomas Bächler
created issue -
| Component/s | Original: credentials-plugin [ 16523 ] |
| Assignee | Original: Stephen Connolly [ stephenconnolly ] |
Currently behaving as designed, though I agree this would be useful. How it could be implemented given current APIs, I have no idea. SCM.checkout has no way of telling the SCM plugin that it should ignore the Job owning its argument for purposes of resolving a credentialsId. In other words I think implementing this feature would require changes to core, the SCM plugin, and workflow-cps-global-lib (and probably also workflow-scm-step).
Thomas Bächler
added a comment - From my point of view It's certainly not "behaving as designed", since I can select the credentials in the configuration, the feedback from Jenkins is that the repository can be accessed, but a failure occurs when the job is run.
Proper behaviour would be that the System credentials cannot be selected on the configuration page.
Thomas Bächler
added a comment - From my point of view It's certainly not "behaving as designed", since I can select the credentials in the configuration, the feedback from Jenkins is that the repository can be accessed, but a failure occurs when the job is run.
Proper behaviour would be that the System credentials cannot be selected on the configuration page. Well…the checkout is behaving as designed. The fact that you are able to select system-scoped credentials in this context should be considered a bug, unless and until the checkout can be improved to permit system-scoped credentials. Not that I am sure how to accomplish that either—again there is no API for it.
Isa Vilacides
made changes -
| Labels | New: remoting-whitelist |
Isa Vilacides
made changes -
| Labels | Original: remoting-whitelist |
I think that's exactly what I need. Only my global shared libraries should have access to certain credentials, transparently for users. These credentials shouldn't be available in a Jenkinsfile.
Flávio Augusto Valones
added a comment - - edited I think that's exactly what I need. Only my global shared libraries should have access to certain credentials, transparently for users. These credentials shouldn't be available in a Jenkinsfile.
Sounds like something relevant to the CPS global library plugin. Nothing relevant to the credentials plugin. Unclear if this is a bug or an RFE (need guidance from jglick as to what the intended scope resolution is for loading libraries, but it would seem reasonable to me to expect that loading a global library defined at the root of Jenkins (not in a folder) should be able to use SYSTEM scoped credentials (especially if the drop-down is listing them as valid)