-
Bug
-
Resolution: Unresolved
-
Blocker
-
None
I have the following in a declarative pipeline job:
pipeline { agent { label "centos7" } stages { stage("github => pending") { steps { githubNotify status: "PENDING", description: "Build is starting...", credentialsId: "my-credentials", account: "me", repo: "the-repo" } } // ...
When the job runs, I get the following in the console output:
java.lang.IllegalArgumentException: The suplied credentials are invalid to login at org.jenkinsci.plugins.pipeline.githubstatusnotification.GitHubStatusNotificationStep.getGitHubIfValid(GitHubStatusNotificationStep.java:234) at org.jenkinsci.plugins.pipeline.githubstatusnotification.GitHubStatusNotificationStep.getRepoIfValid(GitHubStatusNotificationStep.java:239) at org.jenkinsci.plugins.pipeline.githubstatusnotification.GitHubStatusNotificationStep.access$100(GitHubStatusNotificationStep.java:75) at org.jenkinsci.plugins.pipeline.githubstatusnotification.GitHubStatusNotificationStep$Execution.run(GitHubStatusNotificationStep.java:344) at org.jenkinsci.plugins.pipeline.githubstatusnotification.GitHubStatusNotificationStep$Execution.run(GitHubStatusNotificationStep.java:326) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47) at hudson.security.ACL.impersonate(ACL.java:221) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) 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:745)
However, I know that these credentials are definitely valid. In the "Manage Jenkins" page, I can test the credentials via the GitHubPullRequestBuilder plugin, and they work, correspond to a user with read/write permissions on this repo, and can even set commit status (manually, via that other plugin).
The repo in question is a private repo, and the value for "Account" corresponds to an organization, not an individual user account. I suspect the latter is probably what's going on here, but I don't see any better way to specify the org that owns the repo than with the account: parameter.