I am currently setting up a CI system that will check for a passing deployment against a test environment as part of a pre-merge pull request check. This system is using Bamboo and Bitbucket, and will stop devs from merging their feature branches into the main branch if this validation fails. However, I am running into the (possibly common on my project) corner case of multiple pull requests being open at the same time, passing validation, and then being merged. In this scenario the PRs might all separately pass validation while all of them combined would break the build (I.E: PR#1 modifies a method name referenced by PR#2).
Is there a way to configure Bitbucket / Bamboo to rerun builds on pull requests if the target branch has been modified since the check last ran?
On git (bitbucket) level you could make sure to synchronize any feature or bugfix branch with an outgoing pull request by merging the latest common target branch (for example develop) immediately after a successful pull request merge to this target. This way you invalidate the 'latest' build result on feature or bugfix branches and they would be re-built because their git commit hash has changed. If any re-build of the feature branch fails, it won't be merged.
Ulrich
// Izymes - our mission is to eliminate boring from work. We build apps that turbo-charge team velocity through contextual automation.
Related
I am using TeamCity Enterprise 2021.2 (build 99542) and Bitbucket Server v7.14.0. I have a build configuration in Teamcity with 3 VCS roots: Repo1, Repo2, and Repo3. Each repo has a "main" branch, which is the default branch for all 3 repos. Repo 1 and 2 have a branch called "feature1".
If I set the branch specification in all 3 repos to refs/heads/* and set up a VCS trigger to Repo1 with the filter as +:* the desired behavior is achieved. A build is triggered when a change is made to feature1 in Repo1, and the build checks out feature1 on both Repo1 and Repo2, while main is checked out on repo3.
The problem is that I only want to trigger a build when a pull request is created or updated in Repo1. So, I use the Pull Request build feature to trigger with any pull request in Repo1, and set the branch specification in Repo1 to refs/heads/main (so duplicate builds aren't triggered) This results in almost the desired behavior.
I create a PR for feature 1 in Repo1 in bitbucket. And a build is triggered. The problem is that feature1 is only checked out in Repo1 but NOT Repo2. Is there any way to configure a VCS root for Repo2 to check out the same branch that is being used on Repo1 while builds are being triggered by PRs to Repo1?
I suspect the problem is related to some of the TeamCity build configuration variables. In the first case with the expected behavior, teamcity.build.branch is set to refs/heads/feature1. yay. In the second case, teamcity.build.branch is set to pull-requests/## while teamcity.pullRequest.source.branch is set to feature1.
It is not even a problem of variables, but a problem of the build (logical) branch.
If you are using the Pull Requests build feature it (internally) expands the branch spec of the VCS root in the context of your build configuration with patterns that include refs/pull-requests/123/from kind of branches provided by Bitbucket Server for pull requests.
So the logical branch name for the build becomes pull-requests/123, not a source branch of the pull request. As other repos do not have such pull requests in them, for them default VCS branches are selected. Which is in most cases ok, as such things as multi-repo pull requests are not supported by any VCS hosting. Not in my knowledge at least. In our opinion in most cases the following improvement could be useful for many users: to fall back to a VCS branches that match the target branch of the pull request instead of the default branch of the VCS root. This is to be discussed if such feature requests appear.
Anyway your case is different and it seems you want to use source branches in all three repos. If the following feature request is fulfilled it may satisfy your needs: https://youtrack.jetbrains.com/issue/TW-70491
We are currently working on it and it may appear as an experimental feature in one of our bugfix releases soon and as a proper feature in the next feature release this year. Please follow that issue to keep updated.
Cheers,
Anton
I have an Teamcity server with a bitbucket server repository. On the Teamcity is a build pipeline which is used to validate pull requests setup. And basically it works as expected. But while new pull requests are triggered within a minute, when I commit changes on a pull request it can take up to an hour until Teamcity has the changes in the build configuration page. As soon as it does find them, it triggers the build as expected.
It also doesn't make a difference if I select the "check for pending changes" in the Actions menu.
Strangely on my other build pipline, which builds changes on the master branch new commits are triggered within the minute as well.
Pull Request Build Feature:
My branch specifications:
The "Changes checking" settings:
And the trigger:
We use TeamCity Professional 2019.2 (build 71499)
EDIT1: I just realized that there are two different views for changes: one for the branch and one for the pull request. The changes do show up in the branch for the pull request very quickly, but not in the one for the pullrequest.
Branch view:
Pull Request view:
As a reference those screenshots where made 16:32.
EDIT2: I used this article to set it up: https://www.jetbrains.com/help/teamcity/2019.2/pull-requests.html
EDIT3: I just found out that I can trigger the build with browser the pull request on the Bitbucket Server page. No idea how that works though.
It seems this is by design of Bitbucket Server:
https://community.atlassian.com/t5/Bitbucket-questions/Change-pull-request-refs-after-Commit-instead-of-after-Approval/qaq-p/194702
TLDR: The Refs on pullrequest branches are not updated immediately, due to performance consideration. The easiest way to trigger it is to view the PullRequest on the Bitbucket Server website.
Comments, and ref updates to the master will also trigger it when I understoot that correctly.
Does the TeamCity build feature Pull request automatically build a pull request against master? I'm not talking about merging automatically into master just building against it.
I can't seem to find any documentation. Previously in TC I could see two kinds of branches 33/merge and pull/33, with the build feature enabled I can only see pull/xx being triggered. In the build summary it does state Submitted into refs/heads/master, from xxxx-pull-request by xxxxxx
So I can only assume it is running the pull request against master based on the text above, however I can't seem to find any documentation to indicate this.
It is not automatic, it depends how vcs root is set
To build PR revision merge with current master set VCS root +:refs/pull/(*/merge)
See https://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/
I currently have my BitBucket set up to follow the Git flow model (https://datasift.github.io/gitflow/IntroducingGitFlow.html) and have my Bamboo CI running against the develop branch.
What I want to know is if I can set up BitBucket to only approve and/or merge a pull request from a feature branch if that merge would not break the build on the develop branch.
So if we have a pull request to merge branch feature/amazing-new/feature the pull request will only be closed and the branch merged in to develop if Bamboo can do the merge and build successfully.
I've had a look around and only seen answers that refer to build plans that run against the feature branch itself and the BitBucket docs only have paragraph covering builds and pull requests: https://confluence.atlassian.com/bitbucketserver/checks-for-merging-pull-requests-776640039.html
Bamboo can be configured to build merge result: https://confluence.atlassian.com/bamboo/using-plan-branches-289276872.html#Usingplanbranches-Branchupdater
When new commit in feature branch detected it will merge feature branch to master in working copy, build and send result to Bitbucket. At Bitbucket side you can configure pull request settings to not allow PR merge if there're broken builds.
We have multiple layers of our products split into different build configurations for continuous integration. For the sake of this question, let's just say we have a "Front-End CI" build, and a "API CI" build. The VCS roots are configured to pull in all branches, and triggered to run upon checkin, as should be expected for CI.
Now I have my User Acceptance project, where I use CloudFormation to dynamically spin up servers to which I deploy. I have snapshot dependencies set up for the CI builds mentioned above, and everything works as expected for the default branches on each of the VCS roots and dependencies. I expect that a feature branch for the front-end may not necessarily necessitate a branch from the default for the API, and the current way I have it setup accounts for that as well.
That's where I begin to have issues. If I have to branch both the front-end and API, I cannot get TeamCity to do what I want in this regard. My question is this: how do I tell Team City to run a UA build using branch "A" from the Front-End CI build config and branch "B" from the API CI build config, where "A" and "B" can be any arbitrary branch? Currently right now, all branches from both snapshots are shown when I look at the UA build config. Here's a good picture:
If I run api-branch, it will always use the default branch from the Front-end CI snapshot. Same for any branch on the front-end snapshot. I cannot seem to find a way to specify this in the configuration or when starting a build.
I'm up for just about anything to address this, including build configs that are just cloned off of each other to specify branches the way they're meant to, but I'm just not seeing how I can do that either. Thanks!
Create a teamcity template target which monitors both the front end and API repositories and can trigger on changes. This should be one target (and not 2 different targets). Parameterize the branch names so that actual targets have to give the branch name
I would suggest creating a mapping of the frontend:api branches in a datastore( file,db,nosql) . Then dynamically create teamcity targets (through REST API) for each new/modified combination and explicitly set the branch names. Once the targets are created they will automatically run whenver there are any changes.