Advice needed with Teamcity artifact paths - teamcity

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.

Related

File Content Replacer having no effect on artifacts

I'm using a relatively new feature of TeamCity: File Content Replacer. In my current setup I have a version.js file in my VCS:
window["MyPlugin"].version = "1.0.##VCS_REVISION##.##CI_BUILD_NUMBER##";
I use the File Content Replacer build feature to replace that last part with:
%build.vcs.number%.%system.build.number%
So far so good!
I have one relevant build step. It's an MSBuild step, but it does nothing except call a ps1, which does two relevant things:
Moves all js files to an "output" folder;
Zips all js files into a "zips" folder;
Those are also my two artifacts (an output folder, and a zip file).
However, the File Content Replacer reverts its changes, but this revert is also reflected in artifact nr 1, which are files that are not under version control (even though they are located as a subfolder of my project folder). The version.js file in the zip file is not reverted.
If I change artifact 1 to be my/output/folder => all.%build.vcs.number%.zip then the zip file will also contain a reverted state instead of the output I want.
How do I set TeamCity up so that the artifact files are not affected by this revert? Or do I need something other than this Build Feature?
I'm using TeamCity 9.1.3 build 37176 running on Windows 2012 Server (VM) and the default database for evaluation purposes. I'm using TFS 2013 as my VCS.
PS. I've also asked about this on the JetBrains forums.
File content replace reverts changes before "Publishing artifacts" stage. This is "by design". You can check it in the build log. However you can find modified files in hidden artifacts .teamcity/JetBrains.FileContentReplacer/.
If you want to publish changed file as regular artifact you should create a copy of the file (or pack/archive it as as you've already done). Also instead of using File Content Replacer build feature you can create a script that would make needed changes which aren't reverted.

Create a Deployment Package to folder TeamCity

I currently have Team City set up on a server that does:
1) Build the Project
2) Run unit tests
3) Publish the project through IIS if successful
I want to add another step so that a .zip file is produced consisting of what was deployed to a directory on the server running team city. I am to understand that this is possible through artefacts but everything I've tried so far hasn't worked to give me the publish output.
I've tried options such as "** => C:\TC\Test.zip" but that includes the actual code implementation files.
Is there a way in which to publish a zip containing the publish result?
I've been trying this for hours without luck so far so hopefully I can get an answer.
You can use this to zip all files relative to the root of the build:
**/* => artifacts.zip
To zip all files relative to a folder named publish:
publish/**/* => artifacts.zip
If your published files are not included in the zip, they may have been published to someplace outside of the root of the build.

TeamCity - How to publish one output dll into many directories?

I'm trying to publish one of the output dll's to multiple artifact directories. But it seems, that teamcity is publishing that dll only to the last directory.
I would like to have something like this:
MyTool\MyTool.dll => MyZip.zip!/MyTool1/
MyTool\MyTool.dll => MyZip.zip!/MyTool2/
And on output:
MyZip.zip
MyTool1/MyTool.dll
MyTool2/MyTool.dll
But TeamCity returns me only last line:
MyZip.zip
MyTool2/MyTool.dll
Does anyone know how to publish one dll from builds output to multiple artifacts directories?
I spent some time looking for a workaround. It seems like the zip file is the sticking point. If it doesn't need to be zipped, then the following works fine:
MyTool\MyTool.dll => MyTool/MyTool1/
MyTool\MyTool.dll => MyTool/MyTool2/
Another option is to create a build step that moves the DLLs into the folder structure that you want, and then save that folder as the zipped artifact.

How to access test artifacts from Jenkins if test fails

I have a Maven project which performs a number of time consuming tests as part of the integration-test Maven cycle. I'm using Jenkins as the CI server.
During the integration test a number of files are produced in the target folder. For example, an "actual" BMP file is produced and compared to an "expected" BMP file. If the test fails, I need to look at the files in the target folder to determine how to deal with the error. Maybe the actual BMP looks fine and so it should be promoted to the new expected BMP. On the other hand, it may reveal a problem that requires a code fix.
The thing is I don't have any way to get access to these files, other than to ssh into the CI server and manually scp the files over to my own machine for closer inspection. It would be extremely helpful if I could access these files from the Jenkins web interface.
I tried using the build-helper-maven-plugin to attach the relevant files as Maven artifacts, but the problem is that there is no suitable phase in Maven that executes after an integration-test, if any test fails.
What can I do? Can I use the "Copy Artifact" plugin for this?
1) The files in the target folder can be accessed using a link such as /ws/projectname/target/filename...
2) Rather than typing the url each time, the SideBar plugin can be used to add a link to the file to Jenkins' left menu, making it easily accessible.
You need to copy your files into your workspace in a build step and archive them from there - Jenkins lets you specify artifacts only relative to the workspace.
I usually create a directory keyed by the BUILD_ID in the workspace, so that artifacts from different builds do not get mixed up in case I do not clean the workspace and archive from there (specifying ${BUILD_ID}/**/* in the archiving step).
In case your build fails before it can run the copying step and because of it does not do the copy, take a look at this question.

How to configure Hudson to archive empty folders

I have the following sample / test configuration that has Hudson create a directory of empty folders. Its then instructed to archive everything within that folder, except it will not match empty folders and ends up archiving nothing. Whats more annoying is that Hudson does not alert you that nothing matches the search string "root**", but when it builds, it says nothing matches the search string.
(source: 86th.org)
We need Hudson to archive these empty folders for our installer since its expecting them. I fear this may not be possible because of the text "Files to archive".
At any rate, How can I configure Hudson to archive empty folders as an artifact.
You should create the artifact that you want in your build scripts, and then have hudson archive that file. So if you want a zip file that contains empty folders, do the appripriate zip command in your batch file or ant script. Then archive the output file.
Looking at the Hudson source code, it seems as if artifact archiving is meant to only match against files.
You might want to file a feature request or send an email to the USERS list, the Hudson team is pretty good about replying to requests and/or adding features in new releases.
I see three ways:
have your application NOT expect the folders but create them on demand.
or have the application create the folders at startup.
or you could just add dummy files in the folders :) just thinking out of the box.

Resources