It will be a great help if you can isolate the component upgrade which actually caused the change.

The git plugin switched from using credentials 1.x to credentials 2.1 as part of the change from git plugin 2.5.3 to 2.6.0. If you're running git plugin 2.6.0 and you downgrade to an earlier version, do the credentials again appear?

I downgraded to the following versions, unfortunately no luck:

• Credentials Plugin: 2.1.0
• Git client plugin: 1.21.0
• Git plugin: 2.6.0

As far as I can remember though there was a major git/credentials upgrade recently? E.g. the above versions where when the problems started (which was right after I upgraded Jenkins to 2.7.4) - the git 3.0.0 / git-client 2.0.0 only came a few days afterwards which I was hoping would fix the issue.

However, after doing a manual install of the Git plugin 2.5.3 (http://updates.jenkins-ci.org/download/plugins/git/2.5.3/git.hpi) - my creds are back!

I am curious why I am the only one having this issue and if there is something else maybe actually going wrong?

Update: fwiw, on another setup with Jenkins 2.11 I am not having the issue - e.g. everything works with latest git/cred plugins. However there are also only a handful of plugins installed..

I don't know why you're seeing that behavior. Are there any other differences you've detected between the working environment and the broken environment?

The working environment is completely different:

• far less plugins installed
• did not upgrade from the 1.xx, but was a fresh 2.x installation
• far less jobs configured

I will try to replicate it on a VBox.

@Gunter For info I can reproduce it with docker image: jenkins:2.7.4

arnaudlamy can you give more details of the steps you take to reproduce the problem with the docker image jenkins:2.7.4? I tried the following steps and was unable to see the issue:

1. Run docker image jenkins:2.7.4

   docker run --rm -i --dns 8.8.8.8 --publish 9090:8080 -t jenkins:2.7.4
   

   , record the initial login password from the window,

2. Open web browser to http://localhost:9090/
3. Paste the initial login password into the web browser
4. Select the "Install recommended plugins" box, wait for plugins to install
5. Complete the "Create First Admin User" form with my login information
6. Click the "Start using Jenkins" button
7. Click the "Credentials" link on the left side of the screen
8. Click the "Jenkins" credentials scope to open the Jenkins credentials scope
9. Click the "Global credentials" link to open the global credentials folder
10. Click "Add Credentials" to add a credential
11. Enter my github username and personal access token and save that credential
12. Create a new freestyle job named "bin"
13. Use Git as the SCM with the URL https://github.com/MarkEWaite//bin and the credential I previously defined (selected from the pick list)
14. Run the job and confirm that the username / password credential works for that job as expected

I did not apply any limiting conditions to the visibility of those credentials. Maybe you had some additional configuration steps that are relevant?

Indeed I forgot one important element sorry about that. I provided to my docker an old jenkins folder (1.5.X). Here's my command:

docker run --user=jenkins -p 8081:8080 -p 50000:50000 -d --name jenkins --restart always -v /home/jenkins/docker_var:/var/jenkins_home jenkins:${VERSION}

Then I follow the procedure and installed recommanded plugin as well. Then I create a new project, select GIT and click on add to create a new credential. Impossible to list them.

Since then, I installed gitlab auth system plugin and then restarted Jenkins and credentials are listed now !

arnaudlamy it seems that you were able to resolve the issue by updating an unrelated plugin and restarting Jenkins. I thought that lifeofguenter described that a Jenkins restart was not enough to resolve the problem when he saw it. Can you confirm that restarting Jenkins resolves it for you?

Yes it does, do you want that I restart from scratch the test without specifying the old Jenkins folder to my docker?

Yes, since that would confirm that the problem is not visible from a freshly installed Jenkins, only from a Jenkins which has been upgraded from a previous version. My testing is biased (by my docker repository) towards testing fresh installations, so an upgrade related bug needs more careful thought and more test automation to identify the issue and confirm it is fixed.

It would also be a great help if you could provide any hints on what in the older configuration makes it susceptible to this bug. I hope that lifeofguenter could provide similar information.

I restart the test from scratch and everything is fine, I confirm it was due to my old folder to upgrade.

markewaite: I restarted jenkins and the server multiple times - did not help. Also we already upgraded from 1.X LTS to 2.X LTS a longer time ago.

lifeofguenter thanks for the clarification. Unfortunately, I can't duplicate the problem you're seeing. If you can find a way to allow others to duplicate the problem, it makes it much more likely that a fix could be made.

I just upgraded to latest Jenkins ver. 2.19.1 + updated all plugins - this is still a issue.

Anyone any idea how to resolve this problem, or how to further debug this?

I also have same issue. I had setup my jenkins with master container,plugin container and data volume using Rancher. I tried all combinations mentioned above with no luck.
I had installed 2.19.1 , 2.7.1 ,1.653.1 and nothing works.
What I noticed is, with github plugin in global configuration, the credentials do appear. where as while creating project/job it doesn't load. Is there something wrong that Iam doing here?
Regards
Thyaga

thyaga75 since you have it in a container, can you duplicate the problem in a container that could be shared publicly? I can't duplicate the problem, and a publicly accessible container which shows the problem repeatably might make it much easier to diagnose.

markewaite I used rancher catalog to create the jenkins instance.
here is the docker and rancher compose details
docker
jenkins-plugins:
image: rancher/jenkins-plugins:v0.1.1
jenkins-datavolume:
labels:
io.rancher.container.start_once: 'true'
entrypoint:

• chown
• -R
• 1000:1000
• /var/jenkins_home
  image: busybox
  volumes:
• /var/lib/docker/jenkins-cicd:/var/jenkins_home
  jenkins-primary:
  ports:
• 8080:8080/tcp
  labels:
  io.rancher.sidekicks: jenkins-plugins,jenkins-datavolume
  io.rancher.container.hostname_override: container_name
  entrypoint:
• /usr/share/jenkins/rancher/jenkins.sh
  image: jenkins:2.19.1
  volumes_from:
• jenkins-plugins
• jenkins-datavolume
  rancher
  jenkins-plugins:
  scale: 1
  metadata:
  plugins: |2+

jenkins-datavolume:
scale: 1
metadata:
plugins: |2+

jenkins-primary:
scale: 1
metadata:
plugins: |2+

I am having the same problem...this is quite frustrating. I see no errors in the log file.

Interestingly, on the same view (configure system) my credentials are showing up. Looks like a bug, no?

Here's a shot of my installed github plugins:

Same problem here. Git plugin v3.0.0 and Jenkins 2.19.1

A pre-release build of the 3.0.1 release of the git plugin is available if you'd like to try it. It includes the fix for this problem.

I tried it now (and restarted Jenkins) but unfortunately, the problem is still there. Like Paul Pollack, I can see the credentials properly in the system configuration but not on job configuration.

kralleman and paul_symphony I am unable to duplicate the problem you're seeing. Can you provide more details about the conditions when you see the problem. Steps I checked:

Global Pipeline Credentials (as fixed by Jesse Glick's PR437 for JENKINS-38048)

1. Add a global pipeline library named "globalPipelineLibraryMarkEWaiteprivate"
2. Configure the global pipeline library "globalPipelineLibraryMarkEWaiteprivate" to use git as "Legacy SCM"
3. Click the credentials drop down before entering any URL, confirm all credentials appear
4. Enter a private URL in the "Repository URL" field
5. Click the credentials drop down after entering the URL, confirm only credentials for that private repository appear
6. Observe that intentionally invalid credentials for that private repository can be selected but show red text that they don't authorize access to that private repository
7. Observe that valid credentials for that private repository do not show red text when they are selected

Job Credentials

1. Define a new job "JENKINS-38126-credentials-dropdown-empty"
2. Use Git as the SCM for that job
3. Confirm that the credentials dropdown for the job shows all credentials prior to entering any repository URL
4. Enter a repository URL
5. Confirm that the credentials dropdown for the job shows only credentials matching that repository URL (I checked with a private github.com URL and a private bitbucket.org URL)
6. Save the job
7. Confirm that the job runs successfully (clones from the private repository, etc.)

Fresh Install and Job Credentials

1. Refer to my earlier comment

Could you explain further what you are seeing? Specifically, I'm not clear on the steps you took so that you could

see the credentials properly in the system configuration but not on job configuration

paul_symphony, as far as I can tell, you're reporting a different problem (can't see credentials when defining a global pipeline library rather than the bug that lifeofguenter reported that he can't see credentials in an individual job). The "can't see credentials when defining a global pipeline library" was reported as JENKINS-38048 and is resolved in git plugin 3.0.1

It seems as if I tried to use the wrong credentials. I added credentials as part of the configuration of the GitHub Pull Request-builder plugin (according to these instructions https://github.com/jenkinsci/ghprb-plugin). I tried to use those together with the regular git-scm-configuration for a job. When I added a separate (user/password) credential for that part of the configuration (i.e. the regular git-scm-configuration) it worked.

I am still not sure if I should've been able to choose the ones configured for the GitHub PR-builder plugin, but it might very well be the case that I am lacking some understanding of how those are supposed to work. Sorry for the confusion.

markewaite that sounds right, thanks.

I upgraded:

• jenkins: 2.19.4
• git-plugin: 3.0.1

Problem still remaining, similar to what kralleman is describing. Unfortunately I have yet again to downgrade the git-plugin manually to 2.5.3.

Obviously a error is happening, can someone in this thread be so kind to at least help with debugging? E.g. there surely must be somewhere a error log happening?

lifeofguenter, you say you're seeing something similar to what kralleman is seeing, yet he says, "it seems as if I tried to use the wrong credentials". Please review the credentials you're expecting to see in that drop-down menu, and confirm that they are either private key credentials (for ssh and scp git URL's) or username / password credentials (for https URL's). Those are the only two credential types supported by the git plugin.

If there is an error log, you should be able to find that error log from the Jenkins system level logs. If you find that error log, please post it to the bug report, since it will provide additional hints.

The single most effective thing you can do is provide a way to duplicate the problem. Step by step procedures are the best, since then someone else can perform those same steps and see the problem. The empty global credential dropdown includes the steps I use to see the problem. As far as I understand, that's not the problem you're having. Please provide detailed steps which show the problem on a freshly installed system.

I can not reproduce it with another installation, thats what makes me think it is an incapability issue with the xml config files? Since everything works with an older version of the git-plugin there must surely be a change that is regressing? E.g. I can 100% proof that this is an issue with git-plugin > 2.5.3 as it will fail reliably, just can not proof any reproducing steps

E.g. simple reproducing:

• upgrade to anything > 2.5.3
• go to any job
• "creds with id xxx-xxx-xxx-xxx not found"

Fix:

• downgrade back to 2.5.3
• go to any job
• any ssh + private key credentials are selectable

(sorry, this gets long winded )
I'm seeing the same behavior on my system right now. I had this issue some time ago, but never had the time to investigate it very thoroughly.
My current "live" system is
Jenkins 1.651.1
Git Plugin 2.4.4
Credentials Plugin 2.1.4
This setup works. A few months ago I upgraded all my plugins. This upgraded the git plugin to 3.0.0, and I started seeing this behavior of not being able to select any credentials. The only thing that got things working again was to downgrade my Git plugin to 2.4.4.

Fast forward to today.
I'm currently testing a procedure for migrating my Jenkins environment to a new server.
I moved all my content over.
Fire up jenkins (same version 1.651.1) every thing works fine.
I try upgrading my server to 2.32.1. Jenkins comes up, everything looks fine.
I try updating all my plugins to the latest... Git Plugin no longer lets me select any credentials. If I add new credentials, I don't see them. I see them in the credential manager, but not in the Git SCM section
So that puts me here:
Git Plugin 3.0.1
Credentials Plugin 2.1.10

So at this point I try downgrading to version 2.4.4 as my system gives me that option. After downgrade, git credentials work. That was expected. Anyway, now I think that maybe I should try uninstalling the git plugin and reinstalling (This isn't my live box, so I'm willing to screw around with it.). I had to uninstall a bunch of plugins that depend on the Git Plugin. So I get it off, restart, then reinstall the Git Plugin. Same result. I can't see any credentials. Btw, I can't see any credentials on upgraded jobs, or brand new jobs.

so that is where I stand at this point. Unfortunately I can share my image with anyone. I am willing to try stuff out if anyone has any ideas...

I have been doing some changes on the system in the meanwhile, unfortunately same problem:

1. completely re-installed the server from scratch (minimalised the master) on Debian 8, latest Java, latest Jenkins LTS
2. only kept the /var/lib/jenkins folder
3. removed the bitbucket plugin which was causing a lot of problems with jenkins cron runner (e.g. crons would intermittently just fail)

Still, once updating git, the drop down mal-functions. Is there any way for me to produce a log so it can help here? Obviously there must be an error happening? Or is this the desired behaviour?

Only in my first day of Jenkins use but I found I had to create my secret text credential in the global domain to get it to show as an option in the GitHub Server configuration on the Jenkins Configuration page .

Okay, I've done some fairly exhaustive testing (pretty much blunt force style) and I've found what is causing MY Jenkins installation problems. Keep in mind this may not be your cause, but it directly causes the unwanted behavior. I setup a secondary environment, installed all my plugins, copied over my jenkins configuration files (site and plugins) then started removing plugin configurations one by one (restarting the jenkins process as I went along).

My problems seem to be stemming from the "Authorize Project Plugin"
https://wiki.jenkins-ci.org/display/JENKINS/Authorize+Project+plugin

I have a this plugin installed. Under "Configure Global Security" I have set a "Project default Build Authorization" strategy set to "Run as Specific User". The other options here are:
"Run as User who Triggered Build"
"Run as anonymous"
"Run as SYSTEM"

If this value is set to "Run as Specific User", or "Run as anonymous" I lose my ability in my job configuration screen to select any credentials for get to use.
This also seems to apply if I use "Per-project configuable Build Authorization" instead of "Project default Build Authorization".

I'm not sure where the issue lies here. Is it the Git Plugin, or the Authorize Project Plugin?

mwilson, I owe you a beer! This was exactly the reason for our problems as well.

I switched "Project default Build Authorization" to "Run as User who Triggered Build", which fixes the problem of the git-creds dropdown, but for that I am now getting the following warnings on downstream builds:

09:24:01 Warning: this build has no associated authentication, so build permissions may be lacking, and downstream projects which cannot even be seen by an anonymous user will be silently skipped

Downstream jobs still seem to be triggered, but they are not anymore directly linked within the console-output.

To me the security setup of Jenkins does not fully make sense:

• why can downstream jobs just not assume the user that triggered the upstream job?
• why can there not be a "special" user that can be used for scm-polling/trigger/timer? Some documentations suggest SYSTEM is anonymous?

lifeofguenter I'll take it! 

I'm also experimenting with "Run as User Who Triggered Build".  Its a compromise for sure.  Running everything as one user solves a lot of little issues.  I'm not sure if this fault lies with the git plugin, the credentials plugin, or the authorization plugin.  I do know it would be nice if this worked... 

we also ran into this problem and it was difficult to trace.

Will the git plugin be fixed ?

bernhard_merkle you may want to check git plugin 3.6.2 which was just recently released. stephenconnolly I believe that detected a case related to the authorize project plugin and included that in one of his changes.

stephenconnolly has noted that the git plugin needs to change to use a newer credentials API as the best solution. It definitely has not made that change yet.

thanks markewaite for the fast feedback.

We have git plugin 3.6.2 installed and the problem is still there, so the fix of stephenconnolly seems not to fix the bug.

the bug behavior is described exactly as in the comment above (authorize plugin and git plugin coexisting)

https://issues.jenkins-ci.org/browse/JENKINS-38126?focusedCommentId=289182&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-289182

This issue is still relevant with Jenkins ver. 2.176.2, git plugin 3.0.0-rc and Authorize Project 1.3.0

It has been almost 3 years since this was reported and there is nothing more than a workaround? Is there an alternative to the Authorize Project Plugin?

As the usage of the "Authorize Project" plugin is now recommended on the "Manage Jenkins" page, I think many more users will hit this issue.

I can reproduce this issue with Jenkins 2.176.2, git-plugin 3.11.0, authorize-project-plugin 1.3.0, credentials-plugin 2.2.1.

I also checked with other SCM plugins. The credentials drop-down is correctly filled for subversion-plugin 2.12.2 and mercurial-plugin 2.8.

I tested the behavior of the combination of git-plugin, credentials-plugin and authorize-project-plugin and I believe this issue is caused for following three issues:

There're three underlying issues causing this issue:

1. Why this happens only for "Run as specific user" , not for other strategies like "Run as User who Triggered"?:
   • Because credentials in configuration pages are not for the user of builds, but for the user of the job. Jenkins can say that the user of the job is "user1" when you are using "Run as specific user" with "user1" though Jenkins cannot decide the user of the job when you are using "Run as User who Triggered" as the user can be decided only after a build is actually triggered by someone. So "Run as User who Triggered" results configuration pages behave just as when no authorization strategy is set. And this issue is specific to "Run as specific user".
2. What is credentials for specific users?
   • You can configure user-scoped credentials in the user page, which can open from the link over the user name in the right-up part of Jenkins web UI.
   • I suppose many users configures only system-scoped credentials and this results "no credentials are shown".
3. Why system global credentials are not displayed in the job configuration pages even when the user has Credentials/View permissions?
   • It might be a bug of credentials plugin (I'm not so sure as I don't know much about the design of credentials-plugin). I created JENKINS-58902 and please watch that ticket.

The first and second ones can be resolved as "Not A Defect", as they are designated behavior.
For the third one, I created JENKINS-58902. I believe this issue (JENKINS-38126) can be resolved as Duplicate, and please watch that ticket instead.

Those causes are really complicated and I'm afraid they are beyond my English and difficult to read. I expect someone improve the explanation.
And this ticket lasted for so long time and I might fail to get exactly what happened. Please add a comment or reopen the ticket if you have something that looks not resolved.

Following recommendation from ikedam and closing this duplicate