Latest GitHub Branch Source not scanning with credentials?

[Mark Waite]

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..):

[Devin Nusbaum]

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?

<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-use...@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.
<github-branch-source-scanning-as-anonymous.png>

[Mark Waite]

On Mon, Aug 19, 2019 at 9:13 AM Devin Nusbaum <dnus...@cloudbees.com> wrote:

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?

Mostly correct.  Branch indexing uses anonymous credentials instead of the ones I specified.  That takes a very long time due to rate limits.

It is a public repository, so it will not fail with an error message when not using credentials, it just takes a very long time because it exhausts the anonymous rate limits very quickly.

 

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?

Working and non-working cases are both using workflow-cps-global-lib 2.15.

I'll spend more time today investigating further in an attempt to identify the most relevant differences between the working and the non-working cases.

Mark Waite

 

On Aug 17, 2019, at 12:54, Mark Waite <mark.ea...@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-use...@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.
<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-use...@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.

--

Thanks!

Mark Waite

[Mark Waite]

The root issue seems to be the credentials being defined in the parent folder instead of being defined at the root.  I have several credentials defined in that folder and they were working previously as far as I can tell.  However, I'll need to do more searching to understand which change first introduced the behavior.

--

Thanks!

Mark Waite

[Mark Waite]

To bring this thread to closure, we discovered in a diagnostic session that I had defined the credentials domain to be restricted to hosts named 'github.com'.  That precludes use of the 'api.github.com' host which is needed for the API calls from the GitHub Branch Source plugin.

Define credential domains correctly, and the problem is resolved.

--

Thanks!

Mark Waite