I have a TeamCity setup with two projects building different svn branches from the same repository.
First project is for the trunk (stable), and other is for my development branch.
Whenever I commit something to my branch, trunk build is triggered.
Is that normal and can it be avoided?
I'm using TeamCity 6.0.
Marco, are you absolutely sure that your VCS settings for the trunk project do not include sources from the branch?
You configuration should be something like:
svn://server/root (VCS root)
trunk => . (checkout rules for trunk build)
branch/dev => . (checkout rules for branch build)
In this case, everything should work as expected.
Another thing - if your trunk and branch reference the same SVN external, and there is a change in this external, both builds will be triggered.
You can specify your trigger, e.g. the trigger pattern! Or you can write a custom build trigger :-).
Pattern for the trigger pattern :
+|-:[user][VCS root][path]
Related
I have a TeamCity project :
Commit build
Another build
I want that if my commit build is successful on a generic branch name (if the branch name contains a specific word), another build start. The specific word is toto-ok in the example.
Example:
commit build on develop: do nothing more
commit build on branch feature/blabla-toto-ok-blabla: trigger
the other build
commit build on branch feature/something-else: do nothing more
commit build on branch feature/something-toto-ok-else:
trigger the other build
I only have a develop branch in my repository at the moment.
When I try to create a project from it in Teamcity, I get the following error message:
Cannot find revision of the default branch 'refs/heads/master' of vcs root 'dummy VCS root (jetbrains.git)'
The question i:s how can I create a TeamCity build from repo without master branch? In Jenkins usually it makes no problem to build any branch
open attached VCS Roots of your project
Change Default branch to refs/heads/develop
Branch specification set to +:refs/heads/*
Now your default branch is develop, not a master.
Also, you able to see all branches because of the Branch specification
I have a canary build (BuildA) in TeamCity (10.0.2) that builds master, develop, and all feature/* branches when commits occur.
I'd like to create another build (BuildB) that takes a small set of artifacts from BuildA, and runs FxCop on the files. And I want BuildB to have a Finish Build trigger, so that when BuildA completes for any branch, BuildB will get the artifacts from that branches build and run.
There seem to be some hurdles to setting this up:
When I open the "Edit Artifact Dependency" box, I have to specify a "Build branch", which is a logical branch name, not a wildcard or pattern match. So I don't know how to setup an artifact dependency on all builds coming out of BuildA.
The "Finish Build Trigger" has a branch filter, which looks like I can put "+:*" in to catch all branches, but how does that line up with the "Artifact Dependency" branch name value?
Why dont you just trigger BuildB, which in turn builds BuildA instead.
Then you can get artifacts from that specific build easily.
I have a build configuration that builds following tags "develop", "master" and "hotfix" from my branches.
The problem is my branches are not called hotfix in git. They are called for example "hotfix/v1.1.5".
To change that I use the "Shorten Branch Name" feature from TeamCity. I have to do following in the VCS Root to get what I need:
+:refs/heads/(hotfix)/v1.1.5
You maybe can already see the problem. I have to do this for every new hotfix. Is there a way to get TeamCity to build all hotfix branches under the tag "hotfix"?
I tried this but it is not working.
+:refs/heads/(hotfix)/*
Since GitLab 7.6, or thereabouts, there is a new option to use TeamCity directly from GitLab projects. In the setup there is this message:
The build configuration in Teamcity must use the build format number
%build.vcs.number% you will also want to configure monitoring of all
branches so merge requests build, that setting is in the vsc root
advanced settings.
I'm not sure how this works. Lets say I have a repository Foo.
I have setup a build on TeamCity to listen to Foo with branch specification: +:refs/pull/*/merge
I then fork Foo in gitlab as FooFork, make a change, then request a merge FooFork -> Foo.
But nothing happens to test this merge, which is what I was expecting GitLab to do. If I accept the merge than the build server jumps into action (immediately) and builds twice (master and /ref/master).
I've also set the build configuration to use exactly: %build.vcs.number% as the build number as prescribed, but gitlab doesn't seem to give me any information about the build result.
So I'm a bit confused really as to what exactly this GitLab -> TeamCity integration is supposed to do and whether I'm doing wrong.
I'm currently running GitLab 7.9 and TeamCity 8.1.4
Update:
Seems this use case was not supported prior to version 8 - https://github.com/gitlabhq/gitlabhq/issues/7240
I'm running GitLab 8.0.2 and TeamCity 9.1.1 and am able to run CI builds on branches and merge requests.
I trigger CI builds for specific branches by setting a VCS trigger together with the branch specification +:refs/heads/(xyz*) where xyz is the string for our ticket system prefix since all active branches need to be named after an entry in our issue tracker.
I trigger builds for merge requests via the branch specification +:refs/(merge-requests/*)
Everything works as as expected and lets us know the status of all feature / bug branches and merge requests automatically.
Thanks to Rob's comment linking to the GitLab 8 release notes entry on the merge request spec.
Same problem here. There might be another way, I'm evaluating right now. Since there's no direct way of getting the merged state from the target MR, you have to build it on your own:
IMO there's the following todos
1.) init a bare repo $ git init
2.) add your target repo $ git remote add origin git#your-repo:<origin.group>/<origin.repo>.git
3.) add the remote/feature/to-merge's $ git remote add target git#your-repo:<feature.group>/<feature.repo>.git
4.) checkout your feature branch $ git checkout -b <feature.branch> feature/<feature.branch>
5.) checkout your original branch $ git checkout -b <origin.branch> origin/<origin.branch>
6.) Rebase feature into your original branch $ git rebase <feature.branch>
As stated here [1], GitLab-CE can fire an event on creation of a merge-request,
so all you have to do is building some meta, that can evaluate the WebHooks.
[1] http://doc.gitlab.com/ce/web_hooks/web_hooks.html#merge-request-events