If there are multiple pushes to branch, Bamboo schedules separated builds for every push which creates redundancy on the queue. We only care about the last build with the latest changes for ours pull requests. Therefore, is there any way/configuration to cancel ongoing/scheduled builds if new build is scheduled?
I figured out Enable quiet period option (Quiet period allows you to delay building after a single commit is detected, aggregating multiple commits per build). However, quiet period is not the best way to handle the redundancy on the queue.
Does anybody have any idea?
A few things:
It is somewhat of an anti-pattern to avoid building each time code is committed. If you cancel an ongoing build, you could theoretically go all day without ever knowing if a commit at the beginning of the day broke the build if incoming commits keep cancelling the build. Taking this approach you would lose the benefits of having a continuous integration system.
If you only care about the builds going into your mainline branch then you can edit how branches are built by going to Plan Configuration -> Branches. You can select Manually or "When pull request is created". The latter will only trigger a branch build when the PR is created and is updated.
You can further limit what is running by using the Conditional tasks for Bamboo plugin. While not as clean as not starting a build, you could choose to only execute time consuming tasks when your main branch is building, which would allow for faster execution on branches.
Finally, you could theoretically use the REST API to create your own custom plugin/application that stops builds.
Related
Is there any option to trigger build ONLY for entire pull request (only on merge)? I could not find any info about that option, in triggers settings there is only "Include several check-ins in a build if they are from the same committer" option. Will triggering on "Merged" comment works?
I tried to create a trigger but there's no option for this.
In my team we're using teamcity 2020.2.4.
If you limit your branch spec to only watch master, it will only trigger when commits are made to master. Given that you are performing PRs from feature branches to master, a build set up to only trigger (limited by the branch filter in the CVS root) on new changes, will only trigger once the merge commit (or any other commits made to master) have been made.
The workflow you describe puts some requirements and limitations on the process that you work with and disallowing commits to master from everyone except the build system / VCS is one such rule you could set in place to achieve this.
The other setting you mention, "Include several check-ins in a build if they are from the same committer", will let TeamCity bundle together the changes included in a build, if the commits come in within the allowed time limit (defaults to 1 minute, if I remember right). If this setting is not enabled, all commits - even those which come in one after the other within a very short time frame - will trigger a new, separate build.
I'd generally advise to enable that option and set the timeframe to 1 minute or whichever suits your team the best.
I'm trying to setup a pipeline for running all kinds of tests against pull requests into my repository. Repository is git repo hosted with Bitbucket Server and TeamCity is Enterprise 2019.1.5 (build 66605). There are a few key aspects to the task:
There's a lot of tests. One way or the other tests should run in parallel to achieve reasonable execution time. The tests are already partitioned as separate TeamCity build configurations, each having good enough execution time.
There's much less build agents available for the task, so it's not impossible for a particular build to spend quite some time (up to 1-2 hours) in a build queue.
The result of the testing should be reported to Bitbucket as a single aggregate value. I.e. if there are, say, 3 individual builds from p.1 with two passing and one failing then Bitbucket should receive single "failed" build status.
Ideally, pipeline should be triggered by a feature branch change (refs/pull-requests/123/from in Bitbucket lingo), but checkout merges of the feature branch into target branch (refs/pull-requests/123/merge in Bitbucket lingo).
Given above requirements, I experimented with Composite Build Configuration (https://www.jetbrains.com/help/teamcity/composite-build-configuration.html) as it seemed perfect fit for the job. So I set up single composite build with proper builds from p.1 as snapshot dependencies, "Pull Requests" and "Commit status publisher" build features. It works perfectly, except for one thing...
The only thing I cannot seem to be able to work around is the fact that VCS roots in the dependencies collect changes when the build chain is added to the build queue. This means that because of p.2 (non-negligible max time spent in build queue) some builds end up running against a little bit dated sources. Ideally, I would like to be able to run the builds against the latest sources.
So my question is if there's any way to disable revision synchronization for dependencies? Or maybe I could approach the whole problem in some completely different way without using snapshot dependencies?
Cross-posted at community forum: https://teamcity-support.jetbrains.com/hc/en-us/community/posts/360006745840
I have five TeamCity builds that are triggered to run at 01:00. Since they all run on the same Agent, in effect they are queued to run one after the other. Each build takes between 10-60 minutes to complete.
What I'd like to guarantee is that all five builds are run on the same revision. Currently this is not guaranteed because in case a contributing developer can't fall asleep and decides to commit something at 01:30, all builds that start running after that time will run on a different revision.
My question:
Is it possible to configure a build to use a specific VCS revision from a specific time? E.g., configure a build to use the "latest revision at the time of 01:00 today"?
Any other suggestions on how to deal with this problem would be highly appreciated as well.
One of the builds might be set up to have the others as snapshot dependencies. When that build is triggered (e.g. by schedule trigger), its dependencies will be triggered having VCS revision fixed.
Or even new build configuration might be added, it will do nothing except to triggering its snapshot dependencies (your existing configurations).
You can use independent build(or one of a builds will be a master) configuration with trigger at time you need. New config will starts other configs by PS script which calling REST API "Triggering a Build". You can point specified change for all builds(can be get with API "Get pending changes for a build configuration"). This will guarantee all builds will start with same revision. This way might help if dependencies are unacceptable.
We're using TeamCity 9.0.4.
Our full builds take over three hours. While a build is in progress if new commits come in they get queued with, apparently, a VCS snapshot from the time they were queued (I can't see that behaviour specified anywhere, but it's what I've observed).
So by the time the next build is dequeued there may be many builds queued up as developers have been committing changes. The intermediate builds are usually not useful at this point - we just want it to skip straight to the latest build for that configuration.
Other build systems I've used only queue one additional build per configuration and takes its VCS snapshot at the point it is dequeued. This has the effect we want.
I can't work out how to achieve this with TeamCity. What am I missing?
According to our documentation, TeamCity should perform the following build queue optimizations: https://confluence.jetbrains.com/display/TCD9/Build+Queue#BuildQueue-BuildQueueOptimizationbyTeamCity
If it does not work for you, I'd recommend upgrading your server to the most recent version first, and if it does not help, create an issue in our tracker with details about these builds.
I think you've specified this in your trigger.
Edit Configuration Settings | Triggers | VCS Trigger | Show advanced options | Trigger a build on each check-in
That option should be unchecked. The wording is a little confusing I guess. Even with this unchecked, each VCS commit will queue a build but it won't force them to be built in isolation.
I have a build that polls SVN and checks for changes every hour. if it finds changes it starts building.
Right now if it sees changes and a previous build (from the same job) is running, it will queue the build and start it when the previous build finishes.
Is there an option to disable the queuing of multiple builds ?
Here's a workaround: let one job (Trigger) do the polling and then call the main job (MainJob) that will do the updating and building. You can even use the Parameterized Trigger Plugin to pass the SVN revisions and URIs. You then check off Block build when downstream project is building in Trigger.
To propagate change-sets from Trigger to MainJob use BlameSubversion Plugin.
(BTW, here's a neat trick: Trigger does not have to check out the whole SVN tree, you can check it out by hand with --set-depth empty in the working copy of Trigger).