Shulou(Shulou.com)06/01 Report--

A project, HelloApp, is created in TeamCity, and a Build named HelloAppDailyBuild is created in this project to compile the demo program. In this article, we will describe the basic configuration in Build in detail. The following figure is an overview of the basic configuration of Build:

Name

The name of the Build configuration.

Build configuration ID

Build configuration ID: identify the Build configuration in the system, and the automatically generated rule is: project name + underscore + build configuration name.

For example, to navigate to a page with build configuration, the URL is:

Http://xxxx/viewType.html?buildTypeId=HelloApp_HelloAppDailyBuild

The last parameter is Build configuration ID. This ID is very important, and we use it when we use urls and REST API to request information from the server. On the server, it also serves as the directory name for some configuration files.

Description

As a description, the Description appears after the build name:

Build number format

We can specify a format for build number. Different users always have different needs, and if you want build number to be displayed as a self-increasing integer, you can specify build number as% build.counter%. Build.counter is maintained by TeamCity, or you can specify it manually. The build number format set to% build.counter% looks like this:

We can also specify as:

% build.vcs.number.%

Or

% property.name%

These are some variables maintained by TeamCity. A complete example looks like this:

1.0% build.counter%.% build.vcs.number.MyroomProjectSecretsvn%

Note that it is best to maintain the uniqueness of build number. So build counter should be added to the build number format.

What if you want to build number with a date, and what if you also want to display the serial number of the build in the day? Unfortunately, we can't accomplish this requirement by default, but TeamCity provides good scalability. We can write a plug-in to implement this function:

Build counter

The counter for the number of Build, which you can also set manually. But you know exactly what you're doing.

Artifact paths

Collecting build products needs to be done by specifying Artifact paths. We can divide the path of the product into two categories: the accurate path and the path obtained by pattern matching.

The exact path

If you know the exact path of the build product, you can write the product path directly.

You can also choose from teamcity's tools:

Specify the path by pattern matching

Different pattern matching rules can be separated by new lines or commas, such as:

[+:] source [= > target]

This rule adds files that meet the conditions to the product.

-: source [= > target]

This rule is to remove files that meet the conditions from the product.

The parameters enclosed in square brackets are optional. The rules are grouped according to the parts on the right, and work in turn according to the order in which they appear, such as:

+: * * / * = > target_directory-:**/folder1 = > target_directory

Indicates that everything else is added to the product except the content under the folder1.

Here is the detailed format:

File_name | directory_name | wildcard [= > target_directory | target_archive]

File_name specifies the path of the product file relative to build checkout directory.

Directory_name specifies the path of a directory relative to build checkout directory. All files and subdirectories under the directory will be used as products. The structure of the files in the product in the directory remains the same. But the directory directory_name itself is not included in the product.

Wildcard (wildcards) collects Ant-like-compliant wildcard matching files as products (only "*" and "*" are supported). Wildcards appear in the path relative to build checkout directory. The path of the qualified file in the product will maintain the original path structure.

You can also use parameters in the rules for collecting artifacts. Parameters can be built-in variables in TeamCity or user-defined variables.

The latter part is optional. The directory name followed by = > can be used to specify the directory where the product file is stored.

If the target directory is not set, the product will be placed in the root directory of the build product.

Note that the destination path cannot be an absolute path. Non-relative paths can generate errors in build.

The product files collected by target_directory will be placed in this directory.

The path to the archive file after the product is packaged by target_archive. Supported archive formats are .zip, .7z, .jar, .tar.gz, .tgz.

Here are some common examples:

Install.zip// put all the files in the build checkout directory directory into the archive install.zip as a product. Dist// collects everything in the build checkout directory\ dist directory as a product. Target/*.jar// collects all the jar files in the build checkout directory\ target directory as a product. Target/**/*.txt = > docs// collects all .txt files in the build checkout directory\ target directory and its subdirectories as artifacts. And put all these files in the target directory docs. Reports = > reports, distrib/idea*.zip// puts the contents of the build checkout directory\ reports directory into the reports directory in the product. / / put the files that meet the idea*.zip conditions in the build checkout directory\ distrib directory into the root directory of the product. / / We can also specify the location of the product in the zip archive, for example: results\ result1\ Dir1\ Dir2 = > archive.zipkeeper results will be added to the results/result1/Dir1 directory in the archive file. / / the same archive file name in the product can be used multiple times, such as: +: * / *. Html = > report.zip +: * / *. Css = > report.zipholders.

Build options provides us with other features.

Hanging Build Detection

Probe pending build,TeamCity can detect builds that may be suspended.

What kind of build is considered a suspended build? When the execution time of a build obviously exceeds the average execution time estimated by the system, and the build does not send a message after exceeding the estimated time, the build is considered to be in a suspended state. TeamCity estimates the average elapsed time by averaging the build time that has been run. When we subscribe to notifications from the TeamCity system, we can use suspending as a condition. So that we will be notified when the hang occurs.

Allow Triggering Personal Builds

This feature allows users to build with code that is not submitted to the code base, but requires the support of development tools.

Enable Status Widget

Enable the status widget, this option allows us to get the last build information without the need to use authentication information. It is important to note that in addition to the last build information, we can actually get any build information. But it is limited to getting success/failure/internal error/cancelled information.

We can get information in different ways, such as HTML status widget and REST API.

Let's take a look at how to embed Build information into your web page.

Enable "enable status widget" first:

Create a html page and add the following to head:

@ import "/ css/status/externalStatus.css"

Add the following to body:

Replace the placeholder in the above string with your TeamCity server address and replace xxx with a meaningful Build configuration ID. Then open it in the browser and take a look:

Limit Number of Simultaneously Running Builds

Sets the maximum number of build that can run at the same time.

The main purpose is to prevent all build agent from being used up by one build at the same time.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.