My last build step in my TeamCity 9.1 project configuration uses the SMB deployer to copy files to a shared network drive (which we use to deploy the version to our users).
The copy is performed fine but the deployer somehow creates all the folders in the hierarchy leading to the bin folder. Example:
My configuration is:
Target URL:
\\theserver\thefolder
Artifacts path:
**\ProjectName\bin\Release\* => .
**\ProjectName\bin\Release\Resources\* => Resources
With this configuration, I'm expecting the files to be copied to \\theserver\thefolder\* and \\theserver\thefolder\Resources\*
However, this is the result I get instead: my files are copied to
\\theserver\thefolder\ProjectName\bin\Release\*
\\theserver\thefolder\Resources\ProjectName\bin\Release\Resources\*
How do I go with my artifacts definition so my files are copied to the proper folder? I'm having such a hard time with this syntax
The **\ prefix is causing the artifact path output to include the matched folder hierarchy.
You'll need to use the full path to the Project folder, also if you want to include nested directories, use the **\* at the end of the artifact path:
\path\to\ProjectName\bin\Release\**\* => .
\path\to\ProjectName\bin\Release\Resources\**\* => Resources
For more information, see the artifact path doco, specifically:
wildcard — to publish files matching Ant-like wildcard pattern (only "*" and "**" wildcards are supported). The wildcard should represent a path relative to the build checkout directory. The files will be published preserving the structure of the directories matched by the wildcard (directories matched by "static" text will not be created). That is, TeamCity will create directories starting from the first occurrence of the wildcard in the pattern.
Related
I want to store some additional files in the JAR that gets created. Those files are in a directory that is a subdirectory of a repository which is pulled in via a git submodule.
I want to copy that submodule to my src resources directory before compiling, but I also want to make sure that any old files at that location are removed first.
How can that be achieved best with Maven plugins? I did not find any option to remove any destination files with the copy-resources goal of the maven-resources-plugin and I could not get the maven-clean-plugin to run right before the copy-resources either. So how does one accomplish such a trivial task with Maven?
UPDATE: as mentioned above, the reason why I want to do this is because what is copied should become part of what gets added to the resulting jar (and could potentially be part of what gets compiled). So I need to copy these files into the src directory and NOT the target directory. What should get copied before each build is the input to the build, not an additional output.
There is one flaw in your approach, and it probably explains most of the obstructions you encountered.
During a build, the only directory in which you may write is target. Copying files to src or changing them is strictly discouraged.
The target folder is erased by clean, so no need to tidy up yourself or to manage old files.
The standard maven directory structure includes resources as follows:
src/main/resources
src/test/resources
When a maven build is initiated on a sandboxed environment - e.g. jenkins then all of the artifacts in those directories become available at the sandboxed "current" directory - and without resorting to any paths - either relative or absolute.
But when running mvn test locally the sandboxed environment is not in play: instead it is just the root directory of the project. In this case those resources would seem to need to be accessed via src/main[test]/resources.
Specifically: in a sandboxed environment all of the classes to be run are unpacked into a temporary directory *along with the resources under src/[test|main]/resources*. Therefore: the files/artifacts undersrc/[test|main]/resources` are present in the current directory. The "relative" path to those resources is thus
./
But in the local environment - e.g. running mvn test at the root directory of a local git clone - then the current directory is the git repo root dir. The "relative" path to the artifacts is thus
./src/[test|main]/resources
While I realize the artifacts can also be accessed via classLoader.getResourceAsStream I have apis' that require File access. We use api's like listFiles() and there is also the need to generate files in the given directories using file:// uri as well as literal paths. so we do need file paths.
What can be done here to normalize the paths across these different use cases/environments?
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 use Teamcity to build different packages and want to save those Packages as Artifacts. My Artifact Path in TeamCity is the following:
%system.teamcity.build.workingDir%\**\Release**/*.wsp => Solution
Now TeamCity collects all WSP-Files in any Release-Directory after building correctly. But it is saved including all subdirectories like:
I only want the .wsp-File directly under "solution" without the directory tree.
From TeamCity docs:
wildcard — to publish files matching Ant-like wildcard pattern ("" and
"*" wildcards are only supported). The wildcard should represent a
path relative to the build checkout directory. The files will be
published preserving the structure of the directories matched by the
wildcard (directories matched by "static" text will not be created).
That is, TeamCity will create directories starting from the first
occurrence of the wildcard in the pattern.
http://confluence.jetbrains.net/display/TCD65/Configuring+General+Settings#ConfiguringGeneralSettings-artifactPaths
In your build script ( or additional final build step) you will have to copy the necessary files to a single folder and publish that folder as Artifacts
Instead of copying as #manojlds suggests, you might be able to achieve something by modifying the OutputPath in yout .csproj file, or feeding in an OutDir property override when building a .sln (if you are). Be warned that neither of these approaches are perfect - for example, TeamBuild (the CI server in the Visual Studio ALM Tooling) redirects everything into one directory, which can cause a complete mess and only works for the most simple cases.
I had this issue where I wanted to gather various install files from subdirectories. Adding a PowerShell runner as a build step is quite powerful and solves this nicely...
get-childitem -Recurse -Include *.wsp | Move-Item -destination .
This will move them to the root prior to TeamCity looking at the artifacts, where the basic artifact paths like *.wsp can pick it up for the final output.
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