If I understand correctly, the problem is that in the non-working case, branch 
indexing ends up using anonymous credentials instead of the ones you specified 
(and thus timing out due to rate limits), rather than failing with an explicit 
error message?

I don’t think it should matter, but just in case, what versions of 
workflow-cps-global-lib are you running in the working and non-working cases?

> On Aug 17, 2019, at 12:54, Mark Waite <mark.earl.wa...@gmail.com> wrote:
> 
> I've updated to GitHub Branch Source 2.5.6 and seem to have a GitHub 
> multibranch Pipeline job that refuses to use my credentials when scanning the 
> repository.  The repository is a public repository, but I want it to scan the 
> repository with my credentials so that I can use the larger GitHub API rate 
> limits that are allowed by authenticated access.
> 
> I see a job configuration change from "Repository Scan - Deprecated 
> Visualization" to "Repository HTTPS URL" and I see the addition of the 
> "Validate" button in the user interface to check my credentials.  I've 
> validated the credentials using the "Validate" button, both for the job 
> itself and for the Pipeline shared library that is defined in the job.  I've 
> created a new GitHub personal access token with 'repo' permission, and still 
> can't persuade the pipeline scanner to use the credential.  The credentials 
> I'm using are assigned to the parent folder of the multibranch Pipeline job.
> 
> I have another machine which is able to scan with credentials and GitHub 
> branch source using the same repository.  Some of the differences between the 
> working and the non-working cases include:
> Working - Pipeline shared library is defined at root, not working when 
> defined in the multibranch Pipeline job
> Working - Credentials are defined globally, not working when defined in the 
> parent folder of the multibranch Pipeline job
> Working - Git plugin 4.0 beta release, not working when using git plugin 
> 3.11.0
> I suspect there are many more differences between the working and the 
> non-working cases, but wanted to identify those few in case someone has more 
> insights to offer.
> 
> Has anyone else seen a similar behavior?
> 
> Any pointers of things I should investigate (other than varying the 
> parameters which are different between working and non-working cases, I'll 
> certainly do that)?
> 
> Job configuration screen looks like this (apologies for the wide screen..):
> 
> <github-branch-source-scanning-as-anonymous.png>
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-users+unsubscr...@googlegroups.com 
> <mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/d5bb65d3-7ec7-45ee-bfa6-fbf8d99bd6cc%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/jenkinsci-users/d5bb65d3-7ec7-45ee-bfa6-fbf8d99bd6cc%40googlegroups.com?utm_medium=email&utm_source=footer>.
> <github-branch-source-scanning-as-anonymous.png>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/C67B3A88-4A62-4511-8ECE-C0E060D81C44%40cloudbees.com.

Reply via email to