-
Bug
-
Resolution: Fixed
-
Major
-
Jenkins 2.60.2
Blue Ocean 1.2.1
GitHub Enterprise 2.10.4
-
-
Blue Ocean 1.3, Blue Ocean 1.4 - beta 1, Blue Ocean 1.4 - beta 2
The final step in the GitHub Enterprise creation flow ends with error. Logs contain an error about "invalid scan credentials" (see below). Could possibly be related to GitHub Enterprise version as we've tested mostly against 2.9.2.
Error creating pipeline jimmy: Invalid scan credentials jimmy/****** (GitHub Enterprise Access Token) to connect to https://<URI_OMITTED>/api/v3, skipping hudson.AbortException: Invalid scan credentials jimmy/****** (GitHub Enterprise Access Token) to connect to https://<URI_OMITTED>/api/v3, skipping at org.jenkinsci.plugins.github_branch_source.Connector.checkConnectionValidity(Connector.java:435) at org.jenkinsci.plugins.github_branch_source.GitHubSCMSource.retrieve(GitHubSCMSource.java:830) at jenkins.scm.api.SCMSource._retrieve(SCMSource.java:355) at jenkins.scm.api.SCMSource.fetch(SCMSource.java:285) at io.jenkins.blueocean.blueocean_github_pipeline.GithubPipelineCreateRequest.repoHasJenkinsFile(GithubPipelineCreateRequest.java:340) at io.jenkins.blueocean.blueocean_github_pipeline.GithubPipelineCreateRequest.create(GithubPipelineCreateRequest.java:178) at io.jenkins.blueocean.rest.model.BluePipelineContainer.create(BluePipelineContainer.java:54) at io.jenkins.blueocean.rest.model.BluePipelineContainer.create(BluePipelineContainer.java:50) at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627) at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:343) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:184) at org.kohsuke.stapler.SelectionInterceptedFunction$Adapter.invoke(SelectionInterceptedFunction.java:36) at org.kohsuke.stapler.verb.HttpVerbInterceptor.invoke(HttpVerbInterceptor.java:48) at org.kohsuke.stapler.SelectionInterceptedFunction.bindAndInvoke(SelectionInterceptedFunction.java:26) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:117) at org.kohsuke.stapler.IndexDispatcher.dispatch(IndexDispatcher.java:26) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845) at org.kohsuke.stapler.MetaClass$3.doDispatch(MetaClass.java:209) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845) at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:374) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845) at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:374) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845) at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:374) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:686) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845) at org.kohsuke.stapler.MetaClass$10.dispatch(MetaClass.java:374) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:135) at org.jenkinsci.plugins.ssegateway.Endpoint$SSEListenChannelFilter.doFilter(Endpoint.java:225) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at io.jenkins.blueocean.auth.jwt.impl.JwtAuthenticationFilter.doFilter(JwtAuthenticationFilter.java:51) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at io.jenkins.blueocean.ResourceCacheControl.doFilter(ResourceCacheControl.java:134) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at com.smartcodeltd.jenkinsci.plugin.assetbundler.filters.LessCSS.doFilter(LessCSS.java:47) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter$1.call(ScmSyncConfigurationFilter.java:49) at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter$1.call(ScmSyncConfigurationFilter.java:44) at hudson.plugins.scm_sync_configuration.ScmSyncConfigurationDataProvider.provideRequestDuring(ScmSyncConfigurationDataProvider.java:106) at hudson.plugins.scm_sync_configuration.extensions.ScmSyncConfigurationFilter.doFilter(ScmSyncConfigurationFilter.java:44) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at jenkins.metrics.impl.MetricsFilter.doFilter(MetricsFilter.java:125) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:95) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:138) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at io.jenkins.blueocean.rest.APICrumbExclusion.process(APICrumbExclusion.java:30) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:58) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:92) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:90) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:171) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:82) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:553) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:499) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544) at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:748)
[JENKINS-46996] GitHub Enterprise creation ends with error; logs mention "invalid scan credentials"
jimmyraywv just to confirm, when you created the access token you used the link provided in the Blue Ocean UI? It should have set the "repo" and "user:email" scopes on your token?
I have have tried to make this work by creating the token via the link from BO and via the GitHub Enterprise web client, and the result is the same. I can choose the repo, but when I click "Create Pipeline", the process churns, and then produces an error.
jimmyraywv can you open the developer tools console, and in the "Network" tab capture the last POST request to the /organizations/jenkins/pipelines endpoint? I'm assuming it will be either a 400 or 500 error. Seeing the response data would be helpful.
jimmyraywv request looks normal more or less, can you post the response as well? I'm not sure if it will be the same stack as in the logs, or something else (which might provide a useful clue). The the response will be available in the "Response" tab (two tabs over from "Request') in the Network section of the dev tools.
jimmyraywv cliffmeyers one thing to try is to set up a single multibranch pipeline or a github org via "classic" method - may show a slightly different but more interesting error.
It does seem very unhappy with that credential, so might be worth trying it another way to validate it isnt' the credential (might be hiding another error)
Also what is the exact GHE version?
{
"message" : "Error creating pipeline <USER_NAME>: Invalid scan credentials <USER_NAME>/****** (GitHub Enterprise Access Token) to connect to <URI_OMITTED>/api/v3, skipping",
"code" : 500,
"errors" : [ ]
}
Above is the error 500 JSON response from Jenkins. Interesting to me, is the message: "Error creating pipeline <USER_NAME>". The <USER_NAME> value is my GHE org. When trying to create the pipeline, I obviously select the org, then a repo. There is no mention of the repo here. I guess I thought the pipeline would be connected to the repo here.
So, I upgraded my local OSS Jenkins to 2.73.1, and BO 1.2.4. At issue here is that I am running these tests in Cloudbees Jenkins 2.32.3.2 and local Jenkins OSS. BO is installed in both Jenkins, but only my local OSS Jenkins has the feature to Create Pipelines. When I create MBP jobs in the CloudBees Jenkins, I use the GitHub option and the cred with my GHE username and GHE PAT. It works fine in Cloudbees Jenkins.
In my local OSS Jenkins, when I create the MBP job, then I cannot use the GitHub option, with GHE, and the GHE creds. I have to use the Git option. When I use the GitHub option and select our GHE instance, I get invalid scan credentials errors. If I use the GitHub option and GitHub target, and GitHub creds (username/PAT) It works fine.
In BO on my local OSS Jenkins, I can create the pipeline, but I have to use the Git option, as the GHE option has that "invalid scan creds" error. When I create the pipeline with BO in the local OSS Jenkins, I get these notices that none of my branches have jenkinsfiles. however, they do, and when I edit the BO-created MBP job, in Jenkins classic, I am able to make the MBP work correctly.
I do have a later GitHub API Plugin that in local OSS Jenkins than what is running in Cloudbees Jenkins. I am not sure if this is related.
jimmyraywv in Blue Ocean 1.2, GitHub and GHE pipelines are created as GitHub Organization Folders in Jenkins. This is basically a pointer at your GitHub Org which uses a regex to specify the repositories that should be built. In 1.2, as you create more pipelines from the same org, the regex is adjusted to include more repos but the original GitHub org folder is retained.
In Blue Ocean 1.3, we've changed this so that creation of GH and GHE pipelines just use the simpler Multibranch job, and each pipeline you create results in a separate MB job. The main driver for this IIRC was that we want users to have more flexibility in how individual pipelines are configured, and this was challenging to do in the GitHub Org Folder universe. There is an added benefit that pipelines created from Bitbucket and Git are also Multibranch, so the consistency decreases the likelihood of bugs specific to GH/GHE.
Can you let us know what version of GitHub API you're using? I suspect michaelneale or vivek could identify whether that's known to be problematic and we can try to pin down the issue.
Last question, when you say that the CB Jenkins doesn't "have the feature to Create Pipelines" are you indicating that the create pipeline link on the main landing page is hidden? That's typically due to one of two things: 1. the Jenkins instance doesn't have security enabled, which is required for how credentials are stored (since they are user-scoped), or 2. your user may be lacking the create job permission.
So, the config URL in Jenkins contains ".../api/v3...", so I think it is Version 3. I have asked our GHE folks to verify any point releases.
As far as the "New Pipeline" link missing, I thought it was related to how we provision permissions. And, correct me, if I am incorrect, but BO seems folder agnostic. When I access the BO dashboard from the a specific folder, I won't land in that folder, in the BO dashboard, unless, of course, the folder is actually a Multi-Branch Pipeline. We are using RBAC, and folder-level permissions. So, I can create and run jobs, and when I transition to the BO dashboard, from within a MBP that I just created, I am taken to that MBP execution, but I am still not able to see the "New Pipeline" button. Perhaps it is the difference between how RBAC is implemented at the folder level in our Jenkins, and how/where BO looks for this permission?
jimmyraywv sorry, I made an unfortunate typo: what version of the GitHub API Plugin are you using?
vivek do you have access to a GHE 2.10.4 to try with? or perhaps the stack trace hints at what the problem is with the credential.
jimmyraywv From the looks of exception trace, Its failing validating credentials. GHE is returning an error. In case of bad credential GHE should return 401 status code.
Code that does it is printing actual error received as FINE log. If possible enable FINE logging and report back the error printed along with stack trace.
If you can't do that then try curl command below and report back whether its 200 with user object. In case of error (non 200 response code) please paste the error response.
curl -v -H 'Authorization: token TOKEN' YOUR_GHE_URL/api/v3/user
Our GHE instance is having some issues, once its up I am going to try reproduce it.
Thank vivek for your recommendation. Ran the curl command and saw that the URL I was using was returning a 301. Once I changed the URL in the curl command, I got the appropriate reply, to the curl command, without the 301. Then I tried the create pipeline action in BO and it worked. Thanks for your help.
jimmyraywv was is the v3 portion of the URL that was missing? (if so, there is another open ticket to set a suggested default for that to make it clearer in future)
michaelneale no, that was there. It was an alias URL that worked in my browser. It looks like the 301 was not being followed by the GHE plugin.
jimmyraywv gotcha - do you think the 301 should be followed by an api client? (if so can open a bug somewhere) or is this ok but just not a suitable error message?
Testing Notes:
Seems there are two ways to go about this.
- If we implement a fix for following 301 redirects, include an automated test which verifies that this works.
- If we change the error messaging, include an automated test which checks to make sure the expected error message is presented when needed.
Some security postures frown on apps following 301 redirects. Perhaps you could add a configuration for this, but I would not make it work as the default.
jimmyraywv ah of course - I knew there was a reason why api clients don't follow that way... ok thanks.
cc jimmyraywv