I have created a build configuration in TeamCity (v8.0.1) to automatically build my Github pull requests by setting my VCS branch specification to +:refs/pull/(*/merge) (I followed this blog post).
TeamCity is picking up new pull requests and changes to existing pull requests just fine, however it is kicking off multiple builds per change when I would expect it to only perform a single build.
For example, I pushed up two commits to an existing pull request which resulted in 8 builds being executed by TeamCity. When I look at the changes for each of the builds the change graph is identical except for the commit hash of the pull request's build (at least I think that is what it is), e.g.
I have confirmed that Per-checkin Triggering is disabled in the Build Trigger configuration. I have also confirmed that we are not using any of Github's TeamCity hooks.
Any ideas what the problem might be?
I'm not sure what could cause this, but have you tried to turn on "Quiet Period"
http://confluence.jetbrains.com/display/TCD8/Configuring+VCS+Triggers
Related
When I open a PR on GitHub, several builds are triggered on our external build server, but because of build queuing, they can run at different times.
In the interim, however, I can merge my PR after even one of the builds has successfully run.
I understand that the build server is probably using the Checks API, and that GitHub doesn't know about the check until the build server tells it that the build has started. I think this is the source of the problem because GitHub is just saying, "All the checks I know about have passed."
Is there a way to configure GitHub to expect all of my builds before the build server starts them?
The only similar question I found is the following: Trigger travis ci builds if another git repository updates
Keep in mind that our E2E tests are full stack: we have a live server running, and our tests are run against the UI which hits the server. Nothing is stubbed or mocked.
Now, I can trigger in that way a travis rebuild, however problem arises when I have interdependency between branch and a different repository branch.
So let's say I have 3 repositories: backend, frontend and e2etests. If I create the new branch frontend/foo which requires also the backend/foo, there is no way e2e tests will ever pass because they will run one time with frontend/foo and backend/master and another time with frontend/master and backend/foo.
Did anyone face this problem previously? How did you deal with it?
After a lot of digging it was clear that there is no solution and everyone has their own built-in.
What worked for us is a git pre-push hook, environment variables pointing to our repositories and when you push it asks if you want to use a different branch for the UI project (if you are on the UI, asks if you want to use a different branch for the server project) and by default it uses the current branch for the project you are on. So it's quite fast on push, usually you'll just press ENTER an additional time, the two branches are basically the required dependencies and a travis build will be triggered with an API endpoint.
Works fine so far.
So, I've been using Jenkins for quite a while. I have set up numerous projects with the Github Pull Request Builder plugin to run tests whenever someone opens a pull request, and then trigger some other job (build, push, deploy, etc) whenever the pull request actually gets merged to master.
So, is there any way to set this up with a Jenkinsfile, or the organization folders, or the multibranch build deal?
The github-organization-folder plugin in combination with the multi-branch plugin plugin offers exactly this awesome feature: It scans a whole organization (optionally restricted to certain patterns in repo/branch names) for Jenkinsfiles and automatically adds jobs. This also happens for Pull Requests.
Once the PR is closed, it automatically removes the job.
To avoid arbitrary code execution, an organization member has to trigger building the job (same as for the GPRB plugin). The phrase can be configured in the Jenkins System settings.
EDIT: Under the Advanced section in Jenkins, you find options about what types of PR you want to build. If you build fork PRs, then there's afaik no way to prevent running code without prior inspecting it.
An example, how this looks like:
I have a CI build that is setup in TeamCity that will trigger when a pull request is made in BitBucket (git). It currently builds against the source branch of the pull request but it would be more meaningful if it could build the merged pull request.
My research has left me with the following possible solutions:
Script run as part of build - rather not do it this way if possible
Server/agent plugin - not found enough documentation to figure out if this is possible
Has anyone done this before in TeamCity or have suggestions on how I can achieve it?
Update: (based on John Hoerr answer)
Alternate solution - forget about TeamCity doing the merge, use BitBucket web hooks to create a merged branch like github does and follow John Hoerr's answer.
Add a Branch Specification refs/pull-requests/*/merge to the project's VCS Root. This will cause TeamCity to monitor merged output of pull requests for the default branch.
It sounds to me like the functionality you're looking for is provided via the 'Remote Run' feature of TeamCity. This is basically a personal build with the merged sources and the target merge branch.
https://confluence.jetbrains.com/display/TCD8/Branch+Remote+Run+Trigger
"These branches are regular version control branches and TeamCity does not manage them (i.e. if you no longer need the branch you would need to delete the branch using regular version control means).
By default TeamCity triggers a personal build for the user detected in the last commit of the branch. You might also specify TeamCity user in the name of the branch. To do that use a placeholder TEAMCITY_USERNAME in the pattern and your TeamCity username in the name of the branch, for example pattern remote-run/TEAMCITY_USERNAME/* will match a branch remote-run/joe/my_feature and start a personal build for the TeamCity user joe (if such user exists)."
Then setup a custom "Pull Request Created" Webhook in Bitbucket.
https://confluence.atlassian.com/display/BITBUCKET/Tutorial%3A+Create+and+Trigger+a+Webhook
So for your particular use case with BitBucket integration, you could utilize the WebHook you create, and then have a shell / bash script (depending on your TeamCity Server OS) that runs the remote run git commands automatically, which will in turn automatically trigger the TeamCity Remote Run CI build on your server. You'll then be able to go to the TeamCity UI, +HEAD:remote-run/my_feature branch, and view the Remote Run results on a per-feature basis, and be confident in the build results of the code you merge to your main line of code.
Seems that BitBucket/Stash creates branches for pull requests under:
refs/pull-requests//from
You should be able to setup a remote run for that location, either by the Teamcity run-from-branch feature, or by a http post receive hook in BitBucket/Stash.
You can also use this plugin : https://github.com/ArcBees/teamcity-plugins/wiki/Configuring-Bitbucket-Pull-Requests-Plugin
(Full disclosure : I'm the main contributor :P, and I use it every day)
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