I'm trying to label a build that is made of multiple checkouts like this:
+Root
+-trunk
+--Folder1
+--Folder2
+-Tags
+--ProjectA
+---Build-123
+----Folder1
+----Folder2
where 123 in Build-123 is the build number.
I'm trying to achieve this by using the following labelling rules:
/Root/trunk/Folder1=>/Root/tags/ProjectA
/Root/trunk/Folder2=>/Root/tags/ProjectA
And this labelling pattern:
BUILD-%system.build.number%
I was hoping that TeamCity would create the BUILD-123 tag and copy the contents of Folder1 and Folder2 into it. However I get the following error:
Failed: Failed to set label 'BUILD-123': Svn labeling failed: Cannot copy 'Root/trunk/Folder1', 'Root/trunk/Folder2' to the same directory 'Root/tags/ProjectA/CO-BUILD-123'
I'm using TeamCity 5 with Subversion 1.6
This seems to be a limitation on SVN side. The only solution I've found is to call SVN directly to create the destination folder first (mkdir) then use svnCopy to copy each source into that folder.
It seems we need to have labeling rules such as
trunk => tags # the trunk contains the root of my project
branches/*/ => tags # a branch usually contains the a copy of the root of the project
tags/*/ => tags # a tag usually contains the a copy of the root of the project
this will enable (re)tagging branches and tags without explicitly setting their names.
unfortunately TeamCity does not have such generic rules
Please read TeamCity's docs about this topic:
I suppose you need rules like
/Root/trunk=>/Root/Tags/ProjectA
or
/trunk=>/Tags/ProjectA
depending on where you repository root is.
Related
I have configured the Build steps as below
Created another Build Configuration (e.g. named "Send to SonarQube") and added the dependency on initial configuration
An artifact dependency for ".teamcity/.NETCoverage/dotCover.dcvr" file and getting artifacts from "Build from the same chain".
In the new configuration ("Send to SonarQube") added a Command Line step with the following script:
%teamcity.dotCover.home%\dotCover.exe report /ReportType=HTML /Source="dotCover.dcvr" /Output="dotCover.html"
Added SonarQube Runner to the new configuration and added additional command line argument with "-Dsonar.cs.dotcover.reportsPaths=dotCover.html"
Please suggest
Note: When i have checked the dotCover.html the coverage is showing perfectly. But the sonarqube is showing as 0% covered
Since you are using build chains, you are probably switching directories and SonarQube uses absolute paths. To confirm this, look at the html/[nnn].html files in your working directory. In html -> head -> title, does the absolute path match the source code in your current working directory when you run the report command?
So to summarize, in your "Send to SonarQube", you need to ensure:
You have your source code in the working directory
Your individual [nnn].html files have titles with absolute paths matching the source code in your working directory.
There are a few ways to ensure #2:
Way #1
Tell TeamCity to run all snapshot dependencies on the same agent.
Make sure your VCS setup is exactly the same. (For myself, I had excluded some folders in my "Send To SonarQube" equivalent, and that caused a different working directory)
Way #2
Override the Checkout Directory in your VCS setup for everything in the build chain to point to the same absolute directory.
(I haven't tried this, but it should work across agents since the agent name isn't in the directory path)
We have a maven project for which we have set up jenkins for build. The reporsitory has a large tools folder which i didn't want Jenkins to download.
I just want jenkins to download src folder and pom.xml file.
I added two reporsitory locations in Jenkins - only to learn that Single file checkouts are not possible
This forced me to use shell script option provided by Jenkins for checking out pom .xml . PFB the script outline.
svn checkout $pomUrl . --depth empty
svn update pom.xml
I did not find an option in my scm plugin of Jenkins to do an empty checkout
Checkout one file from Subversion
But POLL SCM of jenkins is only polling the src folder and builds are not triggered if i make some changes to pom.xml. Is there a way to ensure Polling of my pom.xml as well?
No. Jenkins will poll what it knows.
In your scenario:
Jenkins doesn't know about your pom.xml.
Jenkins doesn't work in single file checkouts anyways.
You will have to rearrange your structure, either move the tools folder outside of the main checkout (if it's so large that it's prohibitive, why do you have it in the root location?), or move the pom.xml into the src folder.
Edit:
Here is an idea. Haven't tried so don't know if that will work.
Keep your manual checkout and update of that pom like you currently do.
Setup another SVN Add module....
Enter the root location of SVN where your pom is, give it a non-conflicting folder name
Configure Repository depth for that module as Empty (if you don't see this option, you may need to upgrade your SVN plugin and/or Jenkins).
Click Advanced... section.
Configure Included Regions with the path to your src folder, and the pom only.
Something like:
/trunk/myapp/src/.*
/trunk/myapp/pom.xml
For a .NET Developer, the Teamcity artifact paths are not very straightforward.
Per project I do, I have a folder called BuildTools and, within it, folders called Drops and Inputs (drops being the reports and outputs inputs being the config files for various command line apps).
BuildTools/Drops/NDependOut => GenericSolution/Drops/NDepend
Is this correct? BuildTools is from the root of the (custom) checkout dir, and then GenericSolution is from the root of the artifacts path (Called "Artifacts" folder).
The other problem I have is that the NDepend report has a lot of images etc in the same folder as the .html file. How would I upload this? Do I upload the entire folder (in which case, is the syntax above correct?)
In general this is right. TeamCity has an option to zip artifacts before publish. For that use the following syntax
Folder/folder/*/ => destfolder/archive.zip
Another trick is to use TeamCity service message to publish artifacts dynamically from build script.
I have a project in XCode 4 using subversion over ssh. It's configured with the branches, tags and trunk subdirectories and my project (let's say ProjectOne) is its own directory in trunk like so:
-|-trunk
| \- ProjectOne
|-tags
\-branches
I have the relative paths to the three directories configured in XCode like so:
Trunk : trunk
Branches : branches
Tags : tags
And all three have a green 'light' next to them. I have created a branch for my project called ProjectOneBeta using the organiser, the svn tree now has this structure:
-|-trunk
| \-ProjectOne
|-tags
\-branches
\-ProjectOneBeta
\-ProjectOne
If I checkout the project (with trunk/ProjectOne selected) it will check out by creating it's own directory in my Objective-C directory. When I go to switch a branch the structure gets all screwy though. It then becomes:
-ProjectOne
\-ProjectOne
Can anyone help? Have I checked in the code incorrectly initially? Should there not have been that initial subdirectory in trunk? Am I checking it out wrong? Or do I simply have the relative paths set incorrectly despite the green?
I concluded that the configuration was correct but the initial checkin was wrong. I moved all the stuff up one level so the code & project was just in 'trunk'. Works fine now I just have to remember to check out to a named directory.
How do I copy files from a folder to the same folder in the target archive?
Below is what I came up with based on the documentation.
file_name|directory_name|wildcard [ => target_directory|target_archive ]
%env.PROJECT%/EnvironmentSpecificAppSettings/* =>EnvironmentSpecificAppSettings | ..\..\..\..\..\..\..\Artifacts\CI\Website.%system.build.number%.%system.build.vcs.number.PROJECT_CI%.CI.zip
I know of three options.
As sharma noted, you can use artifact paths in General Settings, which will allow you to describe a mapping of files on the buildAgent to files in the archive. You can use absolute or relative paths here. I don't think I've ever tried using property expansions there.
You can also use service messages - by emitting a message with a special format to output, you can issue a number of different commands to TeamCity, including a command to publishArtifacts
You can also use a simple file copy in your build to the appropriate directory in the archive. TeamCity sets properties with the names of the folders that you will need - teamcity.buildConfName, teamcity.projectName, teamcity.agent.dotnet.build_id, etc.
If you are talking about the artifact paths in General settings. Suppose you want the fodler 'Artifacts' in check out dir of the teamcity to be generated as artifacts in Artifacts.tgz then you may want to say:
%system.teamcity.build.checkoutDir%/Artifacts => Artifacts.tgz