My TeamCity CI has the plugin GitHub Commit Hooks provided by Jetbrains to detect new pull requests and trigger a run. I've installed this plugin and configured it clicking here:
After that, the web hook is created on GitHub but the address is 0000:8111 which is wrong. So I change to the correct DNS and redeliver the request.
It seems to work, the server returns 202 with the message Scheduled checking for changes for 2 VCS roots. (Server time: 20180615T122359.142+0100) but the trigger is not working.
After a while another problem happens, the server starts rejecting the requests and GitHub returns this:
No stored auth data (secret key) found for public key "72WE45221-19fe-433b-9265-66b2168EW6c". Seems hook created not by this TeamCity server. Reinstall hook via TeamCity UI.
Environment:
TeamCity version: 2017.2.4 (build 51228)
GitHub Commit Hooks version: 62
What I can do to solve this issue? Is there any issue with my DNS?
EDIT 1:
Now I am able to trigger the build by commits and solved the secret key issue. But pull requests are not triggering the CI.
To solve the secret key issue, you need to change the Server URL on Global Settings.
A bit of a workaround, but have you tried using a VCS trigger to detect and build pull requests rather than a commit hook? This works the same as any other VCS check in trigger, so if your current configuration is already detecting VCS changes from Github it should be more straightforward to setup.
Pull requests on Github are automatically referenced using the following pattern +:refs/pull/*/head so with a VCS branch specification you can have a TeamCity build project that's dedicated to building pull requests.
See https://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/
I had a similar issue; the solution is to change the TC installation's settings so it's aware of its correct URL, and then re-adding the webhook through the plugin. The setting in question is Administration > Server Administration > Global Settings > Server Url:
Related
Our Company used to self-host GitLab for source-code management and configured webhook on gitlab to trigger all the project pipelines on jenkins. Initially, the gitlab url was 'https://git.fulcrumdigital.com' and later for an upgraded version, they changed url to 'https://autobuild.fulcrumdigital.com'
Recently, we migrated to 'github.com' and created an organization. The source codes for various projects are found under this organization, which is private. Now, when I try to configure webhooks for these projects, I see that they deliver as intended to jenkins, but jenkins doesn't trigger the respective project's build. Instead, it gives out a message as shown below.
jenkins-github webhook error
I don't find any info regarding this webhook on global configuration page.
Here is a snapshot of jenkins logs
jenkins logs
I don't face this webhook issue for newly created pipeline-projects on jenkins. I face this issue for older pipeline-projects that already had their webhook configured earlier for gitlab.
Help me to resolve this issue and make jenkins trigger build from github webhook for older pipeline-projects.
Did you try force regenerating the webhooks?
Go to Manage Jenkins > Configure System > GitHub plugin > Advance > Re-registers hooks for all jobs.
I had this problem myself. The first thing you want to do is go to Manage Jenkins -> Configure System scroll down to the GitHub section and click on "Advanced". You will see this:
It's important to have access to your Jenkins log (I'm running Jenkins with Docker). When I clicked on Re-register hooks for all jobs, I got the following error:
In my case, the error mentioned something with my access token. So, I checked my Github personal access token and it turned out, I need to turn on Read and Write for Webhook:
Now, go back to Jenkins and click on Re-register hooks for all jobs again, and on the next push, the build was automatically triggered.
Regards,
Your help will be appreciated.
I have created a pipeline in VSTS\Azure-DevOps. It gets its sources from a repository in Bitbucket. Queueing a build works fine. It builds and the tests succeed.
Now I want a build to run on every commit to the repository on Bitbucket. However, when I edit the pipeline and in the Triggers tab enable 'Continuous Integration' and click 'Save' I get the following error:
Unable to configure a service on the selected Bitbucket repository. Bitbucket returned the error 'Forbidden: '.
I am confused that I get 'Forbidden', while getting the source-code already works.
What is it that I am doing wrong? Is there something I must configure in VSTS\Azure-DevOps or in Bitbucket?
Answering my own question:
It appeared that in Bitbucket I only had the rights of 'Writer' for the Repository. When we changed it to 'Administrator' enabling Continuous Integration worked and we verified that committing a code change triggered the build.
Good news / bad news.
It looks like - for now - you can configure a pipeline without being a BitBucket admin on the repo... but not using the templates.
So you can build an empty pipeline based on a BitBucket repo (no admin access), and manually add each of the tasks.
Based on further tests: what you cannot do is set the Continuous Integration trigger, because that requires admin access to set up the webhooks
I know, this is not what you want... but at least there is a way to end up with a working pipeline.
Regards,
Jose
I was wondering if there is a way to have a Build Status ticker on my GitHub Repository's readme file, if the JENKINS SERVER IS RUNNING ON A LOCAL MACHINE?
Since the JENKINS Embeddable+Build+Status+Plugin requires to have a public url, you can instead use only the GitHub plugin.
See "Show current state of Jenkins build on GitHub repo": since issue 19775, it should be able to use the GitHub API to directly set the build status.
Almost breaking my head over this for last few days but the github plugin for sonarqube (v 5.3) just does not seem to work.
I have my java app code in github, and have configured Jenkins to run mvn sonar:sonar goal on pull request.
The maven settings are:
clean site sonar:sonar
-Dsonar.analysis.mode=preview
-Dsonar.github.oauth=<OAUTH_TOKEN>
-Dsonar.github.repository=<ORG>/<REPO>
-Dsonar.github.pullRequest=${ghprbPullId}
-Dsonar.github.endpoint=<ENT_GITHUB_API_BASE__URI>
For sonar.analysis.mode, I tried 'issues' too
Now I perform foll:
make change to a fork (introduce a violation as per configured quality gate)
commit and push to fork repo
Create a pull request
run the jenkins job using above configuration
The analysis is successful, and the plugin always reports that all checks have passed and changes can be merged. I am just not able to understand why the github plugin in sonar is not able to show violation occured and checks have failed.
Now if I merge the pull request and run sonar analysis in publish mode on the master repo, it says quality gate failed and I am able to see this in SonarQube dashboard for the project with the statement that Quality gate has failed
What am I doing wrong here? My guess is the github plugin not able to compare the changes in the pull request with that in the master repo and hence not able to report the violation. How do I fix that?
Update:
If at the end, I merge the pull request to master repo and re-run the sonar analysis on the original pull request (the one that got merged), it does report the violation as comments in the Pull Request conversation. (But what is the point if sonar is going to report the violations after the pull request is merged???)
Currently, my team is using TeamCity to automatically build pull requests from GitHub.
We have a configuration to build all the pull requests. In the version control settings of the config, our branch specification is
+:refs/pull/*/merge
In the "Build Triggers" configuration setting, we have only one trigger with the following trigger rule:
+:root=Pull Requests on our Repository:\***/*\*
"Pull Requests on our Repository" is our VCS root name.
The issues:
When someone views a pull request on GitHub website without doing anything else, a build would be triggered in the TeamCity build agent. This is quite annoying, because from time to time, we have multiple build agents building the same pull requests (when multiple people view it).
When someone comments on a pull request, a build would also be triggered.
From my perspective, the only time I want TeamCity to start a build is when new commits are pushed to the pull requests.
Is there a way to do it?
Github's refs/pull/*/merge branches are updated every time mergeability of the branch is recalculated, i.e. on every commit to destination (most likely master) branch. They are also updated when pull request is closed and then reopened. Github's support says these branches are not intended for end users use. The only workaround at the moment is to run builds on refs/pull/*/head branches automatically and on refs/pull/*/merge branches manually.
Do you have TeamCity configured as per this blog post? I then activate the TeamCity service hook in GitHub which takes care of triggering a build in TeamCity whenever there is a push. This seems to do the right thing for me. Or am I missing something?
I know this is old but I wanted to post what we've found as alternatives:
Stop using VCS roots altogether as a mechanism for triggering pull requests. Instead, configure a GitHub webhook to notify a web app of yours whenever there is an update to a PR and only then trigger a build via the TeamCity REST API.
In your build config, add a step that checks what changed in the PR. If nothing changed (i.e. no new commits were added), or if the PR is closed, cancel the build. The problem with this is that the build queue will still be populated with builds that will then be cancelled. Also, you'd have to store somewhere the last commit that was built in order to do the check.
According to their TeamCity's issue tracker, the issue of the TeamCity.GitHub plugin causing an infinite loop of builds was fixed in v9.0