-
Bug
-
Resolution: Unresolved
-
Blocker
-
Jenkins: 2.103
Github plugin: 1.29.0
GitHub API Plugin: 1.90
OS: Ubuntu 14.04.5 LTS
GitHub Pull Request Builder: 1.40.0
Under GitHub Pull Request Builder configuration Auto-manage webhooks is enabled.
In the GitHub Pull Request Builder added user credentials. User belongs to owners' User's credential tested and are working.
Webhooks management however does not work. For every private repository there's an error message displayed in Jenkins:
There is no credentials with admin access to manage hooks on GitHubRepositoryName[host=github.com,username=ORG_NAME,repository=REPO_NAME]
From the error message it looks like plugin is trying to use organisation name as a user name, so authentication fails.
- relates to
-
JENKINS-60901 GitHub manages hooks even when it has not been configured to do it
-
- Open
-
Hi guys we are struggling with this issue since a few weeks.
What makes it worse is that we disabled the Auto-manage Webhooks as we don't need it but registered a webhook on organisation level instead. Still randomly some webhooks don't trigger a pipeline (maybe 98/100 PRs trigger our Jenkins pipelines, 2/100 do nothing except writing an error message in the logs). In that case we get the same error message as mentioned in the description.
These are our settings in Jenkins:
We use the Jenkins Github Organisation feature. In our organisation we have ~80 repos that are scanned by the plugin. The issue appears totally randomly throughout different repos. We create very simple PRs without descriptions or any fancy stuff and even after thorough inspection I could not find any difference in the PRs that result in an error and those that trigger a pipeline. The issue is always solved by closing the PR and creating a new one immediately afterwards, which is exact same as the one that failed. That new PR triggers the pipeline as expected.
Maybe a hint is, that > 90% of the failing webhooks belong to PRs of a single user, who is also admin of our GitHub organisation (but not Jenkins admin). Again this user also creates the majority of our PRs so if you see it like this, it might be statistically possible that this is coincidence.