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.
Related
For some projects I use the CI service drone.io. Currently every time I make a commit to any of my branches, drone.io launches a build process. In some situations I consider this a waste of energy and resources and thus want to prevent unnecessary builds. Such situations are e.g.: Changed typos in README.md, working on a new feature and thereby committing some immature code
As far as I know there is no branch-wise configuration. However, this thread in the support forum indicates that via the .drone.yml some fine tuning seems possible. But still I do not know how to enable/disable builds on branch-level.
Alternatively, using some special tag in the commit message would also work for me.
You can use the where trigger to target a particular branch only, see where for the documentation.
Using where & branch you can trigger drone builds for changes to e.g. master only to cut down on unwanted builds. Try adding a block like this:
trigger:
branch:
- master
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.
I know that in Build tasks you can get the commit message using $(Build.SourceVersionMessage), but what if you wanna get the same message from a Release task ?
Or how can I pass a that value as variable to the release pipeline ? thank you so much !
You can retrieve it using the REST API. You have the build ID, so you can easily make a REST API call to retrieve the commit message of the commit for that build.
However, let me leave you with some food for thought. I have no idea what you're doing with the commit message, so the following may not be relevant, but in case it is...
What if there are multiple commits between builds? You'll only get the latest commit message, not the commit messages for the commits that weren't built.
What if there are multiple builds between releases?
What if there are multiple releases, but most builds don't go to every environment? E.g. Environment 2 is 10 builds behind Environment 1.
If there is anything less than a 1 to 1 relationship between commit, builds, releases, and releases to every environment in the pipeline of that release, you are going to end up missing commit messages. Probably most of them, especially in higher environments in your release pipeline (even if every build is deployed to the first environment in your pipeline, most builds will probably not be promoted to the last environment in your pipeline).
Have a look at Variable (de|re)Hydration Tasks by Martin Hinshelwood.
These tasks basically allow you to export a subset of variables to a JSON file in a build, publish it as an artifact and import the variables again from the JSON in your release. I use these tasks often in combination with GitVersion to get detailed version information from my builds to my releases.
You can add an agentless phase
and add a Invoke REST API Task.
Another idea could be that you get the message with $(Build.SourceVersionMessage) and make it available to a release process as an artifact for example written in plain text file created during the build and published with the Publish artifact Task.
I'm using TeamCity 2017.1.4 along with GitVersion.
The teamcity project itself consists of many build configurations the first of which is to run GitVersion and then all subsequent steps take a snapshot dependency on this step and pull the version from its parameters.
In most scenarios this works great, however if we create a new branch eg. /release-foo and push this, teamcity will not trigger a build because its already previously built the commit sha, unfortunately we need it to trigger again as even though the commit hasn't changed being in a new branch means it will get a different GitVersion number.
I've tried forcing the snapshot dependencies on the GitVersion build configuration to always be rebuilt but this seems kind of ugly as kind of breaks all other scenarios where this isn't a problem. I also know I could manually trigger the build telling it to rebuild all dependencies and it would work, however I'm curious if there's a nicer way to get teamcity to automatically trigger a build for a commit on a branch if that branch didn't previously exist, or indeed any other way I could approach this.
You could try configuring TeamCity to include different/more GitVersion version variables in the build, including the branch name and possibly version tags. This would provide a way for your build process to differentiate between the same commit on different branches.
See steps 1-5 of this CD post, as well as this detailed blog post on using GitVersionTask for some examples on how to use the additional info in TeamCity.
You can achieve this by triggering the build from a git hook.
As explained here, you can use a the update hook to identify pushed branches (even when several are pushed in a single operation) and for each branch (assuming it passes your triggering rules) trigger a TeamCity build using the REST API.
If you simply amend the commit on the new branch without modifying anything, it will get a new hash because of timestamp changes. I wouldn't consider this a nice solution, but imho it's better than triggering manually.
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.