I have some branches that I use for release release/vX.x.xx.
I want to always run a build for the latest change on any of this branches (the last one modified, I don't care for the other ones) as a scheduled nightly build.
I configured the VCS root to aim to refs/heads/master (the release branch always change so I can't aim to that one as the default)
branch specification: +:refs/heads/(release/*)
In the triggers, I set a Schedule Trigger with Additional Options > Trigger Build in Branches set to +:refs/heads/release/*.
I also tried to set Triggering Conditions > Edit Trigger Rules to +:refs/heads/(release/*)
Although I did all this, and I see the x pending in the Build configuration tab, when the scheduled time arrives, it doesn't build any branch.
How can I set it up so it will always build the latest change on any branch that matches the pattern in my scheduled trigger?
I'm using TeamCity 2019.2.2
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 have a Jenkinsfile. Currently, it triggers only for pull requests and the master branch.
For the master branch, however, I do not want it to build every time it is merged into. Instead, I want it to build only at night, only if there were changes since the previous build, and to combine all those changes.
Is this possible?
Currently, the build triggers are set using the Jenkins configuration, not the Jenkinsfile.
I have multiple VCS roots set up (Core, AuthN, Other). Due to out of control cross-cutting code, when we build Other, we need to download Core and AuthN in order to build a testing database for integration tests. Where I'm having issues is that we'll have up to 3 different branches of each active at any time: Current, Patch, Hotfix. When Other builds, the correct branch of the other 2 needs to come down as well, (e.g. if Other's Hotfix branch builds, it needs to pull Core and AuthN's Hotfix branch). Since these specific build numbers change on a regular basis, I'm uncertain how to get Other to identify which branch it needs.
I have Other set up with 3 VCS roots (one for Other, Core and AuthN), each with their own branchName parameter as the default branch. I also have a series of parameters created that identify what the current patch and hotfix version is for the next releases. I then created a PS script, that uses these values, plus the current branch name (Other's version), to set Core and AuthN branch names, but that build step doesn't run until after VCS downloads have completed. How can I get the correct version of Core and AuthN for a given version of Other
If the branches in the different repositories are with the same name, you can probably use TeamCity feature branches and snapshot dependencies between the different build configurations.
So if the build chain triggers on a change in a particular branch in one repository then TeamCity will do its best to trigger the builds for the corresponding branches in the rest of the chain.
See the screenshot:
If there's a change in 'hotfix' branch of Step1 build configuration (#8), then the corresponding branch is built in Step2. However, if there was a change in the 'alternative' branch that only exists in Step2, then Step1 will be built from default branch which is 'master' in this example (#10).
I would like to create an integration build in VS Team Services, that is triggered when a commit is done to any branch (develop/feature xy) except master.
I am able to create a trigger for this:
but how do i checkout the sources of the branch that triggered the build?
In the task tab, the first step is 'Get Sources' and here i'm only able to choose one branch (the * wildcard is not possible here):
Otherwise for example a build is triggered by a feature branch, but the sources are taken from the develop branch. How can i do this?
You filter is perfectly fine if you want to build anything but master branch.
The branch you select in build definition is just the default branch used when you Queue New Build manually.
OTOH the build trigger establish which branch to download, e.g. if the build has been triggered by a git push on branch develop then that is the one checkout'ed and built.
When you queue a new build manually, you also have the chance to change the default value to whatever branch you would like to build.
We're using teamcity with github enterprise. And we have it set to run on merge requests as well as commits. However, git keeps sending teamcity commit messages for merges that have 0 file changes, which triggers a build.
For example, this will trigger a build:
I've found the documentation here for creating a trigger filter
But I don't see a way to create a filter on the number of updated files.
I think this is what's causing the builds
Triggering a Build on Branch Merge
The VCS trigger is fully aware of branches and will trigger a build once a check-in is detected in a branch.
When changes are merged / fast-forwarded from one branch to another, strictly speaking there are no actual changes in the code. By default, the VCS trigger behaves in the following way:
- When merging/fast forwarding of two non-default branches: the changes
in a build are calculated with regard to previous builds in the same
branch, so if there is a build on same commit in a different branch,
the trigger will start a build in another branch pointing to the same
commit.
- If the default branch is one of the branches in the
merging/fast-forwarding, the changes are always calculated against
the default branch, if there is a build on same revision in the
default branch, TeamCity will not run a new build on the same
revision.
It's worth noting, that builds on branches that haven't been updated will be triggered by a merge in another branch.
You probably use checkout rules. Otherwise, running a build on a merge commit with 0 files seems an appropriate action: the commit does change the content of the checkout directory and should trigger a build.
If you limit what you checkout via TeamCity checkout rules, TeamCity only displays the merge commit with 0 files if it actually changes the content of the checked out directories (by merging files in the directory), or the commit graph is not fully known to TeamCity, and it potentially can affect the checkout.
If you are not running the latest TeamCity release (10.0.5 as of now), it makes sense to update. If you still get merge commits displayed which are not affecting the checked out files and are not merging commits created before the VCS was configured in TeamCity, it makes sense to report the details to TeamCity support.