Icon

You are viewing the documentation of TeamCity 9.x, which is not the most recently released version of TeamCity.
View this page in the latest documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.

 

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: minor formatting

...

Setting

Description

Name

The build configuration name

Anchor
BuildConfID
BuildConfID
Build Configuration ID

The ID of the build configuration (must be unique across all build configurations and templates in the system).

Description

An optional description for the build configuration.

Build Number Format

This value is assigned to the build number. For more information, refer to the Build Number Format section below.

Anchor
buildCounter
buildCounter
Build Counter

Specify the counter to be used in the build numbering. Each build increases the build counter by 1. Use the Reset counter link to reset counter value to 1.

Artifact Paths

Patterns to define artifacts of a build. For more information, refer to the Artifact Paths section below.

Build Options

Additional options for this build configuration. For more information, refer to the following sections below:

Table of Contents
maxLevel5
minLevel4
excludeExplicit Paths|Paths Patterns|Examples:

Anchor
BuildNumberFormat
BuildNumberFormat

...

Pattern

Description

%build.counter%

a build counter unique for each build configuration. It is maintained by TeamCity and will resolve to a next integer value on each new build start. The current value of the counter can be edited in the Build counter field.

%build.vcs.number.<VCS_root_name>%

the revision used for the build of the VCS root with <VCS_root_name> name. Read more on the property.

%property.name%

a value of the build property with the corresponding name. All the Predefined Build Parameters are supported (including Reference-only server properties).

...

  • file_name — to publish the file. The name should be relative to the Build Checkout Directory.
  • directory_name — to publish all the files and subdirectories within the directory specified. The directory name should be a path relative to the Build Checkout Directory. The files will be published preserving the directories structure under the directory specified (the directory itself will not be included).
  • 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.
  • target_directory — the directory in the resulting build's artifacts that will contain the files determined by the left part of the pattern. This path is a relative one with the root being the root of the build artifacts.
  • Anchor
    compressedArtifacts
    compressedArtifacts
    target_archive — the path to the archive to be created by TeamCity by packing build artifacts determined in the left part of the pattern. TeamCity treats the right part of the pattern as target_archive whenever it ends with a supported archive extension, i.e. .zip, .7z, .jar, .tar.gz, or .tgz.

Although absolute paths are supported, it is recommended to use paths relative to the build checkout directory.

The optional part starting with the => symbols and followed by the target directory name can be used to publish the files into the specified target directory. If the target directory is omitted, the files are published in the root of the build artifacts. You can use "." (dot) as a reference to the build checkout directory.

The target paths must not be absolute. Non-relative paths will produce errors during the build. 

...

You can use build parameters in the artifacts specification. For example, use "mylib-%system.build.number%.zip" to refer to a file with the build number in the name.

Examples:
Info

The same target_archive name can be used multiple times, for example:
*/*.html => report.zip
*/*.css => report.zip!/css/


Relative paths inside a zip archive can be used, if needed.

You can use build parameters in the artifacts specification. For example, use "mylib-%system.build.number%.zip" to refer to a file with the build number in the name.

Examples:

...

:
results\result1\Dir1\Dir2 => archive.zip!results/result1/Dir1

  • install.zip — publish file named install.zip in the build artifacts
  • dist  — publish the content of the the dist directory directory
  • target/*.jar  — publish all jar files in the the target directory directory
  • target/**/*.txt => docs  — publish all the txt files found in the the target directory  directory and its subdirectories. The files will be available in the build artifacts under the the docs directory directory.
  • reports => reports, distrib/idea*.zip  — publish reports directory as as reports and  and files matching matching idea*.zip from the  from the distrib directory  directory into the artifacts root.

Anchor
buildOptions
buildOptions

...

This feature allows you to get an overview of the current project status on your company's website, wiki, Confluence or any other web page.
When the Enable status widget option is enabled, an HTML snippet can be included into an external web page and will display the current build configuration status.
For build status icon as a single image, check REST build status icon.

The following build process information is provided by the status widget:

...