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)/*
Related
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
Sonarqube Server Version 7.0 (build 36138)
Sonarqube Branch Plugin 7.0 (build 413)
sonar-maven-plugin:3.4.0.905
Java project
Sonarqube is set up with a master branch already.
As part of a Jenkins build job we execute the following command:
mvn sonar:sonar -Dsonar.host.url=<our host> -Dsonar.projectName=<project name> -Dsonar.projectKey=<project name> -Dsonar.branch.name=${BRANCH}
where BRANCH is set to the branch name we are building in Jenkins.
Analysis appears to work when we build our "develop" branch in that the develop branch appears if it isn't in Sonarqube and the timestamp for the analysis is correct on the server, but there are two issues:
1) I've set "develop" to be a long-lived branch per the instructions in https://docs.sonarqube.org/display/PLUG/Branch+Plugin by modifying the long-lived branch regex in the SQ server to be:
(branch|release|develop)-.*
but I only see the Issues and Code tabs on the "develop" branch display. And in the Jenkins job, I see the message:
[INFO] Branch name: develop, type: short living
which leads me to believe that develop is not being recognized as a long living branch.
2) There is no output in the Issues tab. Only the code tab shows anything. But the master branch output shows 225 issues, so I would expect the same list of issues in the develop branch (since they haven't been addressed).
Questions:
Do long living branches show all of the same output that you
normally see for the master branch, including "Overview"?
Is there something that I need to do to specify the "develop" branch
as long-living in the maven command above?
Any idea why the issues tab doesn't show anything?
Many thanks,
Wes
In my opinion it is your regex you should check first. You are using the default (branch|release|develop)-.* notice that you have added hyphen(-) at the end.
So, sonar expects the branch name to be branch-, release- or develop-. In your case I believe the regex should be (branch|release|develop).*
Seems you hit this:
There's already a Jira ticket
https://jira.sonarsource.com/browse/MMF-1265
https://community.sonarsource.com/t/long-lived-branches-quality-gate-does-not-fail-in-first-analysis/175
I have big problem with configuring TC. It's 10.0.2 version.
I want build chain like this:
Main - Restore nuget and rebuild solution.
Code analysis - Analyse code result(do not checkout) use Main as dependency.
Publish - Publish to Azure - Use result of Main.
I set Main to:
Build numer format:%build.counter%.%build.vcs.number....%
VCS checkout dir: auto
Code analysis
Build number format:%build.counter%.%dep.<mainId>%.%build.vcs.number...%
VCS checkout dir:%dep.<mainId>.build.default.checkoutDir%
And the main dir is: 55660246e9f668c3
And Code Analysis searching in: 9ccd5731845f5aba
So it's wrong. Why?
Why?
EDIT:
What I set VCS checkout directory in "Code Analysis" build configuration to hardcoded directiory name of "Main" e.x. to 55660246e9f668c3 then it work.
So the problem is with %dep.<mainId>.build.default.checkoutDir%
You can set up a snapshot dependency, that builds from the same chain. This will ensure that the same branch, from the same root, with the same revision number (point in time) is checked out to the directory. If you use an artifact dependency, in addition to the snapshot dependency, you can achieve the same point in time consistency. So after your step 1 build runs, regardless of what new changes exist, your second build will be working with the same files your first had.
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
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]