Offhand sounds like a configuration error, though I am not sure. May depend on the particular retrieval method in use.

So, you believe this should work?  I'll try to reproduce from a clean config, if that is the case.

If you mean defining credentials in the organization folder’s configuration screen, then yes it ought to work.

I have the same problem. It's possible to select ssh folder-scoped credentials in the job configuration for the Shared Library, but they didn't work. It only works with global credentials for me. I tested the ssh key and it's correct.

I can confirm the same behavior that wilm is seeing. I created two separate credentials for github access (same content), one inside the global Jenkins store and the other scoped to a folder. When attempting to configure access to a shared library inside the aforementioned folder, the global credential works and the folder credential does not.

I've included an attachment with the error message that shows up in the UI in the latter case.

Here's my current environment:

• Jenkins – 2.60.2
• Pipeline: Shared Groovy Libraries – 2.8
• Credentials Plugin – 2.1.14
• GitHub Branch Source Plugin – 2.2.3

I suspect the problem is that SCMSource.owner is not being set in this context. If so, would probably require API changes coördinated across multiple plugins to fix. TBD.

I can confirm this issue, since I am not experiencing it since JENKINS-45844 has been resolved. The workaround of using the Legacy SCM option still works.

This is a one year old issue and it's blocking us ,when will it be resolved ?

Also waiting on this issue to be resolved. While using the 'Legacy SCM' option works for us, it in turn exposes us to JENKINS-44075 meaning that we can not specify the shared library version to check out in our Jenkinsfile.

Also waiting on this issue to be resolved. The 'Legacy SCM' doesn't work for us, because it doesn't able us to use 'system' scoped credentials. The goal for us is to able people using exposed shared library without having the access to the repository itself.

Also regular GIT checkouts using "Modern SCM > GIT" are affected by this! Are there any plans on fixing this bug in the near future?

Fixed in git plugin 3.11.0 released July 27, 2019

markewaite is there a reason you just marked this issue (and another one similar to it) FIXED BUT UNRELEASED when there is in fact a release with the fix?

Sorry about that mistake. I failed to read the comment which says that it was released in git plugin 3.11.0. Returning to CLOSED since it is resolved.

matthiasbalke, can you confirm that the issue is fixed for "Modern SCM > GIT"?

I get a quite similar issue for linked Pipeline Libraries where branch references can authenticate, but tag references are unable to.

We got the same problem as asbachb describes.

While using "Modern SCM > GIT", trying to fetch tag references fails like this:

...
12:51:26  Fetching origin...
12:51:26  Fetching upstream changes from origin
12:51:26   > git --version # timeout=10
12:51:26   > git --version # 'git version 2.11.0'
12:51:26   > git config --get remote.origin.url # timeout=10
12:51:26   > git fetch --tags --progress -- origin +refs/heads/*:refs/remotes/origin/* # timeout=10
12:51:26  ERROR: Checkout failed
12:51:26  hudson.plugins.git.GitException: Command "git fetch --tags --progress -- origin +refs/heads/*:refs/remotes/origin/*" returned status code 128:
12:51:26  stdout: 
12:51:26  stderr: remote: HTTP Basic: Access denied
...

In case we use a branch it works. In case we use a tag, it doesn't.

When specifying the credential in the global scope instead of folder scope, we can also checkout the tag as intended.

Currently we're using: workflow-cps-global-lib-plugin 2.17

degelma please do not reopen issues in general. You can file a fresh issue in git-plugin with a Link to this one and complete, self-contained, minimal steps to reproduce from scratch.

jglick: Thanks for the info, I'll do that.