-
diff --git a/topics/adding-notification-rules.md b/topics/adding-notification-rules.md
index cf1f430e3..be89ee2ea 100644
--- a/topics/adding-notification-rules.md
+++ b/topics/adding-notification-rules.md
@@ -42,7 +42,7 @@ Make sure your [Version Control username](creating-and-managing-users.md#VCS+Use
-* __My favorite builds only__ — limit notifications to your [favorite builds](favorite-build.md).
+* __My favorite builds only__ — limit notifications to your [favorite builds](build-actions.md#Add+Build+to+Favorites).
diff --git a/topics/agent-requirements.md b/topics/agent-requirements.md
index 1d4489e1e..df115b02c 100644
--- a/topics/agent-requirements.md
+++ b/topics/agent-requirements.md
@@ -1,7 +1,7 @@
[//]: # (title: Agent Requirements)
[//]: # (auxiliary-id: Agent Requirements)
-_Agent requirements_ are special conditions that define whether a [build configuration](build-configuration.md) can run on a particular [build agent](build-agent.md). Together with grouping by [agent pools](configuring-agent-pools.md), they give you a flexible control over how builds are distributed to agents.
+_Agent requirements_ are special conditions that define whether a [build configuration](managing-builds.md) can run on a particular [build agent](build-agent.md). Together with grouping by [agent pools](configuring-agent-pools.md), they give you a flexible control over how builds are distributed to agents.
To create an explicit agent requirement for a given build configuration, go to __Build Configuration Settings | Agent Requirements__ and click __Add new requirement__. Each requirement represents a conditional rule for a certain parameter. While you are entering a parameter name or value, TeamCity will show you related suggestions.
@@ -48,7 +48,7 @@ title="TeamCity tutorial — Agent Requirements"/>
Build Agent
- Build Configuration
+ Build Configuration
Assigning Build Configurations to Specific Build Agents
diff --git a/topics/already-fixed-in.md b/topics/already-fixed-in.md
deleted file mode 100644
index 25925dff3..000000000
--- a/topics/already-fixed-in.md
+++ /dev/null
@@ -1,21 +0,0 @@
-[//]: # (title: Already Fixed In)
-[//]: # (auxiliary-id: Already Fixed In)
-
-For some test failures TeamCity can show the "_Already Fixed In_" build.
-This is the build where this initially failed test was successful and which was run _after_ the build with initial test failure (for the same [Build Configuration](build-configuration.md)).
-
-Here, _after_ means that
-* the build with the successful test has newer changes than the build with initial failure;
-* if the changes were the same, the newer build was run after the failed one.
-
-So, if you run [History Build](history-build.md), TeamCity won't consider it as a candidate for "_Already Fixed In_" for test failures in later builds (in terms of changes).
-
-Tests are considered the same when they have the same name. If there are several tests with the same name within the build, TeamCity counts order number of the test with the same name and considers it as well.
-
-Note that all invocations of the same test within a single build are counted as 1.
-
-
-
- First Failure
-
-
diff --git a/topics/archiving-projects.md b/topics/archiving-projects.md
index ade20de60..a29a84560 100644
--- a/topics/archiving-projects.md
+++ b/topics/archiving-projects.md
@@ -5,7 +5,7 @@ If a project is not in an active development state, you can _archive_ it using t
When _archived_:
* All the __subprojects__ of the current project __are archived__ as well.
-* All project's __build configurations are__ automatically __[paused](build-configuration.md#Build+Configuration+State)__.
+* All project's __build configurations are__ automatically __[paused](changing-build-configuration-status.md)__.
* Automatic checking for changes in the project's [VCS roots](configuring-vcs-roots.md) is not performed if the VCS roots are not used in other non-archived projects.
* Automatic build triggering is disabled. However, builds of the project can be triggered manually or automatically as a part of a build chain.
* All data (settings, build results, artifacts, build logs, and so on) of the project's build configurations are preserved — you can still edit settings of the archived project or its build configurations.
@@ -24,6 +24,6 @@ If you need to dearchive a project, you can do it using the __Actions__ menu in
Project
- Build Configuration
+ Build Configuration
\ No newline at end of file
diff --git a/topics/artifact-dependencies.md b/topics/artifact-dependencies.md
index 3b5fa5518..07e296acc 100644
--- a/topics/artifact-dependencies.md
+++ b/topics/artifact-dependencies.md
@@ -48,7 +48,7 @@ Get artifacts from
Specify the type of build whose artifacts are to be taken:
* Latest successful build: artifacts will be taken from the successful dependency build with the most recent revision (the latest change ID)
-* Latest [pinned build](pinned-build.md): artifacts will be taken from the pinned dependency build with the most recent revision (the latest change ID)
+* Latest [pinned build](build-actions.md#Pin+Build): artifacts will be taken from the pinned dependency build with the most recent revision (the latest change ID)
* Latest finished build: if a snapshot dependency is also configured in a build configuration, artifacts will be taken from the build with the same sources as the current build
* Build from the same chain: this option is useful when you have a [snapshot dependency](snapshot-dependencies.md) and want to obtain artifacts from a build with the same sources
* Build with specified build number
@@ -245,7 +245,7 @@ TeamCity itself acts as an Ivy repository. You can read more about the Ivy depen
where:
* `YOUR_ORGANIZATION` replace with the name of your organization.
* `YOUR_MODULE` replace with the name of your project or module where artifacts will be used.
-* `BUILD_TYPE_EXT_ID` replace with the [external ID](build-configuration.md#Status+Display+for+Set+of+Build+Configurations) of the build configuration whose artifacts are downloaded.
+* `BUILD_TYPE_EXT_ID` replace with the [external ID](changing-build-configuration-status.md#Status+Display+for+Set+of+Build+Configurations) of the build configuration whose artifacts are downloaded.
* `BUILD_REVISION` can be either a build number or one of the following strings: `* latest.lastFinished`
* `latest.lastSuccessful`
* `latest.lastPinned`
diff --git a/topics/assigning-build-configurations-to-specific-build-agents.md b/topics/assigning-build-configurations-to-specific-build-agents.md
index de6e95ce9..4e0a939d7 100644
--- a/topics/assigning-build-configurations-to-specific-build-agents.md
+++ b/topics/assigning-build-configurations-to-specific-build-agents.md
@@ -1,7 +1,7 @@
[//]: # (title: Assigning Build Configurations to Specific Build Agents)
[//]: # (auxiliary-id: Assigning Build Configurations to Specific Build Agents)
-It is sometimes necessary to manage the [Build Agents](build-agent.md)' workload more effectively. For example, if the time-consuming performance tests are run, the Build Agents with low hardware resources may slow down. As a result, more builds will enter the [Build Queue](build-queue.md), and the feedback loop can become longer than desired. To avoid such situation, you can:
+It is sometimes necessary to manage the [Build Agents](build-agent.md)' workload more effectively. For example, if the time-consuming performance tests are run, the Build Agents with low hardware resources may slow down. As a result, more builds will enter the [build queue](working-with-build-queue.md), and the feedback loop can become longer than desired. To avoid such situation, you can:
1. [Establish a run configuration policy](#Agent+pools) for an agent, which defines the build configurations to run on this agent.
2. Define special [Agent Requirements](agent-requirements.md), to restrict the pool of agents, on which a build configuration can run the builds. These requirements are:
@@ -47,7 +47,6 @@ You can also use the condition __contains__, however, it may include more than o
Build Agent
Agent Requirements
- Run Configuration Policy
Triggering a Custom Build
diff --git a/topics/azure-board-work-items.md b/topics/azure-board-work-items.md
index 2b6422de1..2ad61a206 100644
--- a/topics/azure-board-work-items.md
+++ b/topics/azure-board-work-items.md
@@ -6,8 +6,8 @@ You can integrate TeamCity with Azure Board Work Items (or Team Foundation Work
## Displaying Links to Work Items in TeamCity UI
When integration with Azure Board Work Items is enabled, TeamCity automatically detects work item IDs mentioned in the comments of VCS commits. It transforms these IDs into links to the corresponding work items and displays them to TeamCity users in the UI:
-* To see the basic details of a work item in the TeamCity UI, open the __[Changes](working-with-build-results.md#Changes)__ tab of the related build’s results and hover over the icon next to the work item ID.
-* Work items fixed in the build can be viewed on the __[Issues](working-with-build-results.md#Related+Issues)__ tab of the build results.
+* To see the basic details of a work item in the TeamCity UI, open the __[Changes](build-results-page.md#Changes+Tab)__ tab of the related build’s results and hover over the icon next to the work item ID.
+* Work items fixed in the build can be viewed on the __[Issues](build-results-page.md#Issues+Tab)__ tab of the build results.
* To view work items related to a whole build configuration (not only to individual builds), use the __Issue Log__ tab of the __Build Configuration Home__ page. You can filter the list to a particular range of builds and/or enable the _Show only resolved issues_ option to display only issues fixed in the builds.
Additionally, if your changeset has related work items, TeamCity can retrieve information about them and display information in the UI even if no comment is added to the changeset.
diff --git a/topics/branch-remote-run-trigger.md b/topics/branch-remote-run-trigger.md
index 0aa158318..f2b5364a4 100644
--- a/topics/branch-remote-run-trigger.md
+++ b/topics/branch-remote-run-trigger.md
@@ -1,7 +1,7 @@
[//]: # (title: Branch Remote Run Trigger)
[//]: # (auxiliary-id: Branch Remote Run Trigger)
-The _branch remote run trigger_ automatically starts a new [personal build](personal-build.md) each time TeamCity detects changes in particular branches of the VCS roots of the build configuration. Finished personal builds are listed in the [build history](build-history.md), but only for the users who initiated them.
+The _branch remote run trigger_ automatically starts a new [personal build](personal-build.md) each time TeamCity detects changes in particular branches of the VCS roots of the build configuration. Finished personal builds are listed in the [build history](build-results-page.md#Build+History+in+Classic+UI), but only for the users who initiated them.
At the moment, the branch remote run trigger supports only Git and Mercurial VCSs.
diff --git a/topics/bugzilla.md b/topics/bugzilla.md
index c00c49d2e..92b0057bf 100644
--- a/topics/bugzilla.md
+++ b/topics/bugzilla.md
@@ -7,8 +7,8 @@ You can integrate TeamCity with [Bugzilla](https://www.bugzilla.org/) (3.0 or la
When integration with Bugzilla is enabled, TeamCity automatically detects issue IDs mentioned in the comments of VCS commits. It transforms these IDs into links to the corresponding issues in Bugzilla and displays them to TeamCity users in the UI:
-* To see the basic details of a issue in the TeamCity UI, open the __[Changes](working-with-build-results.md#Changes)__ tab of the related build’s results and hover over the icon next to the issue ID.
-* Issues fixed in the build can be viewed on the __[Issues](working-with-build-results.md#Related+Issues)__ tab of the build results.
+* To see the basic details of a issue in the TeamCity UI, open the __[Changes](build-results-page.md#Changes+Tab)__ tab of the related build’s results and hover over the icon next to the issue ID.
+* Issues fixed in the build can be viewed on the __[Issues](build-results-page.md#Issues+Tab)__ tab of the build results.
* To view issues related to a whole build configuration (not only to individual builds), use the __Issue Log__ tab of the __Build Configuration Home__ page. You can filter the list to a particular range of builds and/or enable the _Show only resolved issues_ option to display only issues fixed in the builds.
Follow these recommendations to get the maximum benefit from the Bugzilla integration:
diff --git a/topics/build-actions.md b/topics/build-actions.md
new file mode 100644
index 000000000..c4a214957
--- /dev/null
+++ b/topics/build-actions.md
@@ -0,0 +1,119 @@
+[//]: # (title: Main Actions on Builds)
+[//]: # (auxiliary-id: Main Actions on Builds;Pinned Build;Build Tag;Changing Build Status Manually)
+
+This article describes what actions can be applied to builds in TeamCity.
+
+## Run Build
+
+TeamCity allows running builds:
+* Automatically, with various [build triggers](configuring-build-triggers.md).
+* Manually, on demand.
+
+To run a build manually, click __Run__ in the upper right corner of the screen. This action is available in both __Build Configuration Settings__ and __Build Configuration Home__ modes. If the __Run__ button does not appear for a certain build configuration, it means you do not have enough permissions to start builds in it.
+
+The context menu next to the __Run__ button opens the build's settings menu, so you can initiate a custom build run. A custom run allows using different settings or/and source code than if running a regular build in the current configuration. This is handy if you want to try different build parameters or pretest local code without affecting common build settings or committing the code to the common repository. Read more about this functionality [here](running-custom-build.md).
+
+
+
+## Cancel Build
+
+To cancel a running build, click the stop icon next to its progress bar. TeamCity will prompt to you to enter an optional reason for cancelling; you can also choose if this build should be automatically re-added to the queue.
+
+Note that there is no way to pause and then continue a single build (though you can [pause a whole build configuration](changing-build-configuration-status.md)). If cancelled, a build should be restarted from the first step.
+
+## Build Actions Menu
+
+The following actions can be invoked from the single-build __Actions__ menu. To open this menu from __Build Configuration Home__, click  opposite the build in the list. To open it from the build's __Overview__, click __Actions__ in the upper left corner.
+
+
+
+### Re-run Build
+
+This action will restart the current build only, omitting other builds in its chain if any. It might be helpful if the build failed due to certain infrastructure problems.
+
+### Remove Build
+
+This action will delete the build from the list.
+
+### Pin Build
+
+You can pin a build to prevent it from being removed during a scheduled [clean-up](teamcity-data-clean-up.md).
+
+If the current build is a part of a chain and has [snapshot dependencies](snapshot-dependencies.md) on other builds, you can choose to apply this action to all its preceding builds in the chain.
+
+A pinned build can be unpinned manually anytime.
+
+### Add Tags to Build
+
+Build tags are labels that can help:
+* Organize the history of your builds.
+* Quickly navigate to the builds marked with a specific tag.
+* [Search](search.md) for a build with a particular tag.
+{product="tc"}
+* Create an [artifact dependency](artifact-dependencies.md) on a build with a particular tag.
+
+In the _Edit tags_ dialog, enter one or more tags separated by space, comma, or semicolon. For example, `v2022 release` will create two tags: `v2022` and `release`.
+
+If you click a certain tag when viewing a build list, this will filter out other builds, so you can focus only on the builds with this tag.
+
+Apart from the __Actions__ menu, you can tag a build in the _[Run Custom Build](running-custom-build.md)_ dialog and in the _Pin Build_ dialog.
+
+You can also add and modify build tags using [TeamCity REST API](https://www.jetbrains.com/help/teamcity/rest/manage-finished-builds.html#Manage+Build+Tags).
+
+[//]: # (Internal note. Do not delete. "Build Tagd46e113.txt")
+
+### Add Build to Favorites
+
+[//]: # (Internal note. Do not delete. "Favorite Buildd142e4.txt")
+
+You can add builds to _favorites_ to have quick access to them. Favorite builds can also be set as a filter option for [notifications](set-up-notifications.md).
+
+When added to favorites, a build will be marked with a star icon . Clicking it will remove the "favorite" status.
+
+TeamCity can automatically mark your manually triggered and [personal builds](personal-build.md) as favorites. To achieve this, enable the respective setting in your [user profile settings](configuring-your-user-profile.md).
+
+To view your favorites, click your avatar in the upper right corner of the screen and choose __Favorite Builds__.
+
+### Compare Two Builds
+
+The _Select for comparison_ action of the build's __Actions__ menu (in __[Build Results](build-results-page.md)__) is available only in the new TeamCity UI. You can switch to it from a classic UI mode by clicking the test-tube icon in the upper right corner of the screen.
+
+This action allows comparing the settings and results of the current build with any other build from this build configuration, side-by-side. It shows the statistics and differences of their [parameters](configuring-build-parameters.md), revisions, statistics, and tests.
+
+This mode is especially helpful when the current build configuration is managed and monitored by multiple users. For example, if a build has no changes in the project code but fails for no obvious reason, you can compare this build with the last successful build and analyze their differences to find the most probable cause of the failure.
+
+### Manually Change Build Status to Failed or Successful
+
+Project administrators can manually change the successful build's status to failed, and vice versa. There are following common use cases for this:
+
+* **From successful to failed**:
+ * The build has some problem which did not affect the final [build status](build-state.md), but you want to reflect the problem's presence in the build history.
+ * There is a known problem with the build, and you want this build to be ignored by a QA team.
+ * You have previously mistakenly marked the build as successful.
+* **From failed to successful**:
+ * You need to change the _last successful build_ anchor when using [build failure conditions](build-failure-conditions.md). If your last build failed because of an incorrect value of a metric and this new value is valid, you can mark this build with a _successful_ anchor.
+ * You want to allow using an incorrectly failed build with good artifacts in __[Artifact Dependencies](artifact-dependencies.md#Configuring+Artifact+Dependencies+Using+Web+UI)__.
+ * For a running [personal build](personal-build.md), you can mark the current failures as non-relevant to allow the pretested commit to pass.
+
+The "_Mark as successful_" action is not available for [builds that failed to start](build-state.md#Failed+to+Start+Builds).
+
+### Label Build Sources
+
+TeamCity can label (tag) sources of a particular build in your VCS repository. The list of applied labels and their application status is displayed on the __[Changes](build-results-page.md#Changes+Tab)__ tab of __Build Results__.
+
+You can configure [automatic labeling](vcs-labeling.md) or label each build manually, from the __Actions__ menu. Manual labeling uses the VCS settings actual for the build.
+
+### Merge Build Sources
+
+TeamCity can merge the code of one source branch to another: for example, after an approved code review.
+
+You can configure [automatic merge](automatic-merge.md) or do it manually for each build, from the __Actions__ menu. The pop-up dialog will prompt you to select the destination branch for a merge and enter a merge commit message.
+
+## Build Configuration Actions Menu
+
+The __[Build Configuration Home](build-configuration-home-page.md)__ page has own __Actions__ menu with a different set of actions. It allows you to:
+* [Pause triggers](changing-build-configuration-status.md).
+* Check for [pending changes](change-state.md).
+* Enforce [clean checkout](clean-checkout.md).
+* [Assign an investigation](investigating-and-muting-build-failures.md).
+* [Clean stream workspaces on a Perforce server](perforce-workspace-handling-in-teamcity.md#Cleaning+Workspaces+on+Perforce+Server).
\ No newline at end of file
diff --git a/topics/build-agent.md b/topics/build-agent.md
index aae3005db..d64aa26a6 100644
--- a/topics/build-agent.md
+++ b/topics/build-agent.md
@@ -14,7 +14,7 @@ A TeamCity build agent contains [two processes](configuring-build-agent-startup-
An agent typically checks out the source code, downloads artifacts of other builds and runs the build process. An agent can run a single build at a time. The number of agents basically limits the number of parallel builds and environments in which your build processes are run.
An agent can run builds of any compatible build configuration.
-The TeamCity server monitors all the connected agents and assigns queued builds to the agents based on [compatibility requirements](agent-requirements.md), [agent pools](configuring-agent-pools.md), build configuration restrictions configured for an agent and the selection algorithm described [here](build-queue.md).
+The TeamCity server monitors all the connected agents and assigns queued builds to the agents based on [compatibility requirements](agent-requirements.md), [agent pools](configuring-agent-pools.md), build configuration restrictions configured for an agent and the selection algorithm described [here](working-with-build-queue.md#Build+Queue+Optimization+by+TeamCity).
## Build Agent Status
@@ -47,7 +47,7 @@ An agent is connected if it is registered on the TeamCity server and responds to
>If an agent stays disconnected during 14 days, its state changes to _Unauthorized_. If you try to reconnect it to the server, you will have to authorize it again.
>The default timeout duration (14 days) can be adjusted by changing the `teamcity.server.cleanup.agents.inactivityDays` [internal property](server-startup-properties.md#TeamCity+Internal+Properties).
>
-{type="note"}
+{type="note" product="tc"}
diff --git a/topics/build-artifact.md b/topics/build-artifact.md
index 885723906..a813b3c37 100644
--- a/topics/build-artifact.md
+++ b/topics/build-artifact.md
@@ -13,7 +13,7 @@ TeamCity contains an integrated lightweight builds artifact repository.
Upon the build finish, TeamCity searches for artifacts in the build [checkout directory](build-checkout-directory.md) according to the specified [artifact path or path patterns](configuring-general-settings.md#Artifact+Paths). The matching files are then uploaded ("published") to the TeamCity server, where they become available for downloading through the web UI or can be used in other builds using [artifact dependencies](dependent-build.md#Artifact+Dependency). You can [choose when to publish artifacts](configuring-general-settings.md#publish-artifacts): for all completed builds, only for successful builds, or for all builds, even the interrupted ones.
-To download artifacts of a build, go to the [Artifacts](working-with-build-results.md#Build+Artifacts) tab of the build results page or use the artifacts icon  available on the project or build configuration __Overview__ page and on the TeamCity pages that list the builds.
+To download artifacts of a build, go to the [Artifacts](build-results-page.md#Artifacts+Tab) tab of the build results page or use the artifacts icon  available on the project or build configuration __Overview__ page and on the TeamCity pages that list the builds.
diff --git a/topics/build-checkout-directory.md b/topics/build-checkout-directory.md
index 6e25ff754..891d20c0e 100644
--- a/topics/build-checkout-directory.md
+++ b/topics/build-checkout-directory.md
@@ -19,7 +19,7 @@ By default, this is also the directory [where builds will run](build-working-dir
## Checkout Process
For checkout handled by TeamCity (the [server-side](vcs-checkout-mode.md#server-checkout) or [agent-side](vcs-checkout-mode.md#agent-checkout) checkout mode), TeamCity keeps track of the last revision checked out into each checkout directory on the agent and for the new build applies an incremental patch from the last used revision to the revision of the current build.
-The revisions used can be looked up on the __[Changes](working-with-build-results.md#Changes)__ tab of the build results page.
+The revisions used can be looked up on the __[Changes](build-results-page.md#Changes+Tab)__ tab of the build results page.
Incremental checkouts mean that any files not created or modified by TeamCity (for example, by the previous build scripts) are preserved in their modified state (unless dedicated VCS root-specific reset options are used).
That is why it is recommended to:
diff --git a/topics/build-configuration-home-page.md b/topics/build-configuration-home-page.md
new file mode 100644
index 000000000..cea2a543e
--- /dev/null
+++ b/topics/build-configuration-home-page.md
@@ -0,0 +1,62 @@
+[//]: # (title: Build Configuration Home Page)
+[//]: # (auxiliary-id: Build Configuration Home Page;Maven-related Data)
+
+This article gives an overview of the __Build Configuration Home__ page of the new TeamCity UI. Most of its features are also available in the classic UI mode.
+
+The build configuration details are represented on multiple tabs whose set may vary depending on your server or project configuration.
+
+## Overview
+
+This tab provides information on:
+* Pending changes, also listed as a [separate tab](#Pending+Changes).
+* The current status of the build configuration, and, if applicable:
+ * Number of [queued builds](working-with-build-queue.md).
+ * For a running build, the progress details with the __Stop__ option to terminate the build.
+ * For a [failed build](build-state.md), the number, [agent](build-agent.md), and so on.
+* [Build history](build-results-page.md#Build+History+in+Classic+UI).
+
+## History
+
+_Available only in the classic UI._
+
+_Build history_ is a record of the past builds produced by TeamCity. The __History__ tab allows filtering builds by build agents, [tagging builds](build-actions.md#Add+Tags+to+Build), and filtering them by tags (if available).
+
+## Change Log
+
+By default, lists changes from builds finished during the last 14 active days. Use the _Show all_ link to view the complete changelog.
+
+This tab shows the changelog with its graph of commits to the [monitored branches](build-results-page.md#Changes+Tab) of all VCS repositories used by the current build configurations and the repositories used by the [dependencies and dependent configurations](dependent-build.md) of the current configuration.
+
+## Issue Log
+
+Lists related issues, if [integration with an issue tracker](integrating-teamcity-with-issue-tracker.md) is configured.
+
+## Statistics
+
+Displays the collected statistical data as [visual charts](statistic-charts.md#Build+Configuration+Statistics).
+
+## Compatible Agents
+
+Lists all authorized agents. Agents meeting [agent requirements](agent-requirements.md) are listed as compatible. For each incompatible agent, the reason is provided.
+The agents belonging to the [pool(s)](configuring-agent-pools.md) associated with the current project are listed first.
+
+## Pending Changes
+
+Lists [changes](change-state.md) waiting to be included in the next build.
+
+## Settings
+
+Lists the current [build configuration settings](creating-and-editing-build-configurations.md#Configuring+Settings).
+
+## View Investigation History
+
+The _Investigation History_ action of the __[Actions](build-actions.md#Build+Configuration+Actions+Menu)__ menu gives access to the log of all [investigations](investigating-and-muting-build-failures.md) of the current build configuration. It is most helpful for big teams and projects when it is not as easy to determine who and when changed or resolved the investigation.
+
+To see all the actions applied to an investigation, open its context menu and click __Investigation History__.
+
+
+
+## Maven Tab
+
+You can find information about settings specified in your Maven project's `pom.xml` file on the dedicated __Maven__ tab. It also shows _Provided parameters_: for example, `maven.project.name`, `maven.project.groupId`, `maven.project.version`, `maven.project.artifactId`. You can use these parameters within your build and reference them within the build number pattern using the `%`-notation. For example, `%\maven.project.version%.{0}`.
+
diff --git a/topics/build-dependencies-setup.md b/topics/build-dependencies-setup.md
index 098335d4a..3f5f00f01 100644
--- a/topics/build-dependencies-setup.md
+++ b/topics/build-dependencies-setup.md
@@ -113,7 +113,7 @@ To get an idea of how snapshot dependencies work, think of module dependencies,
-1. If a build of A1 is triggered, the whole build chain A1...AN is added to the [build queue](build-queue.md), but __not vice versa!__ - if build AN is triggered, it doesn't affect anything else in the build chain, only AN is run.
+1. If a build of A1 is triggered, the whole build chain A1...AN is added to the [build queue](working-with-build-queue.md), but __not vice versa!__ - if build AN is triggered, it doesn't affect anything else in the build chain, only AN is run.
2. Builds run __sequentially starting from AN to A1__. Build A(k-1) won't start until build Ak finishes successfully.
3. All builds in the chain will use the same sources snapshot, i.e. with explicit specification of the sources revision, that is calculated at the moment when the build chain is added to the queue.
@@ -147,7 +147,7 @@ In this case it doesn't matter which build - B1 or B2 - starts first. As in the
#### Reusing builds
-All builds belonging to the [build chain](build-chain.md) are placed in the [queue](build-queue.md). But, instead of enforcing the run of all builds from a build chain, TeamCity can check whether there are already suitable builds, i.e. finished builds that used the required sources snapshot. The matching queued builds will not be run and will be [dropped from the queue](build-queue.md#Build+Queue+Optimization+by+TeamCity), and TeamCity will link the dependency to the [suitable builds](snapshot-dependencies.md#Suitable+Builds). To enable this, select '_Do not run new build if there is a suitable one_' when configuring snapshot dependency options.
+All builds belonging to the [build chain](build-chain.md) are placed in the [queue](working-with-build-queue.md). But, instead of enforcing the run of all builds from a build chain, TeamCity can check whether there are already suitable builds, i.e. finished builds that used the required sources snapshot. The matching queued builds will not be run and will be [dropped from the queue](working-with-build-queue.md#Build+Queue+Optimization+by+TeamCity), and TeamCity will link the dependency to the [suitable builds](snapshot-dependencies.md#Suitable+Builds). To enable this, select '_Do not run new build if there is a suitable one_' when configuring snapshot dependency options.
Another option that allows you to control how builds are re\-used is called "_Only use successful builds from suitable ones_" and it may help when there's a suitable build, but it isn't successful. Normally, when there's a failed build in a chain, TeamCity doesn't proceed with the rest of the chain. However, with this option enabled, TeamCity will run this failed build on these sources one more time. When is this helpful? For example, when the build failure was caused by a problem when connecting to a VCS.
diff --git a/topics/build-history.md b/topics/build-history.md
deleted file mode 100644
index 78b5b324d..000000000
--- a/topics/build-history.md
+++ /dev/null
@@ -1,22 +0,0 @@
-[//]: # (title: Build History)
-[//]: # (auxiliary-id: Build History)
-
-_Build history_ is a record of the past builds produced by TeamCity.
-
-To view the history of a build configuration, open its __[Build Results](working-with-build-results.md)__ page. In the upper right corner of the page, click __previous__ and __next__ links to browse through the builds, or click __All history__ link to open the __History__ tab.
-
-Navigation menu:
-
-
-
-__History__ tab:
-
-
-
-[//]: # (Internal note. Do not delete. "Build Historyd38e30.txt")
-
-
-
- Clean-up
-
-
diff --git a/topics/build-log.md b/topics/build-log.md
index 24e6c387c..0ef7ea6f6 100644
--- a/topics/build-log.md
+++ b/topics/build-log.md
@@ -5,7 +5,7 @@ A _build log_ is an enhanced console output of a build. It is represented by a s
## Viewing Build Log
-The log of a specific build is available for browsing on the __[Build Results](working-with-build-results.md#Build+Log)__ page.
+The log of a specific build is available for browsing on the __[Build Results](build-results-page.md#Build+Log+Tab)__ page.
The __Tree view__ is the most capable view provided in the web UI. By default, all messages are displayed. Using the _View_ drop-down menu, you can switch from all messages to viewing __errors__ separately, or you can choose __Important messages__ to see the log filtered by "error" and "warning" statuses. You can also use the "Verbose" view level and download a raw build log using the corresponding link.
diff --git a/topics/build-number.md b/topics/build-number.md
deleted file mode 100644
index e4ab1e640..000000000
--- a/topics/build-number.md
+++ /dev/null
@@ -1,19 +0,0 @@
-[//]: # (title: Build Number)
-[//]: # (auxiliary-id: Build Number)
-
-Each build in TeamCity is assigned a build number, which is a string identifier composed according to the pattern specified in the build configuration settings on the [General Settings](configuring-general-settings.md) page.
-This number is displayed in the UI and passed into the build as a [predefined property](predefined-build-parameters.md).
-
-A build number can be:
-
-* [used to download artifacts](patterns-for-accessing-build-artifacts.md#Obtaining+Artifacts)
-* [referenced as a property](predefined-build-parameters.md)
-* [shared for builds connected by a dependency](how-to.md#Share+the+Build+number+for+Builds+in+a+Chain+Build)
-* [used in artifact dependencies](artifact-dependencies.md)
-* [set with help of service messages](service-messages.md#Reporting+Build+Number)
-
-
-
- Configuring General Settings
-
-
\ No newline at end of file
diff --git a/topics/build-queue.md b/topics/build-queue.md
deleted file mode 100644
index bf644a24e..000000000
--- a/topics/build-queue.md
+++ /dev/null
@@ -1,70 +0,0 @@
-[//]: # (title: Build Queue)
-[//]: # (auxiliary-id: Build Queue)
-
-The build queue is a list of builds that were [triggered](configuring-build-triggers.md) and are waiting to be started. TeamCity will distribute them to [compatible](agent-requirements.md) build agents as soon as the agents become idle. A queued build is assigned to an agent at the moment when it is started on the agent; no preassignment is made while the build is waiting in the build queue.
-
-When a build is triggered, first it is placed into the build queue, and, when a compatible agent becomes idle, TeamCity will run the build.
-
-## Build Queue Optimization by TeamCity
-
-By default, TeamCity optimizes the build queue as follows:
-* if a similar build exists in the queue, a new build (on the same change set and with the same custom properties) will not be added
-* if an automatically triggered build chain has more changes than a build chain that is already queued, the latter will be replaced with the automatically triggered build chain, if such replacement will not delay obtaining the build chain results (based on the [estimated duration](#Build+Queue+Tab))
-* while a build chain is in the queue, TeamCity tries to replace the queued builds with equivalent started builds
-* builds that have been staying in a queue for longer than 15 days are canceled automatically (for example, if there are no compatible agents).
-
-This default behavior can be manually disabled via the corresponding option in the [VCS Build Trigger](configuring-vcs-triggers.md) and [Schedule Build Trigger](configuring-schedule-triggers.md).
-
-## Build Queue Tab
-
-The list of builds waiting to be run can be viewed on the __Build Queue__ tab.
-
-This tab displays the following information:
-* The number of the build in the queue which is a link to the [build results](working-with-build-results.md) page.
-* The __branch__ (if available).
-* The __build configuration__ name in the following format: __<project name>::<build configuration name>__, where the project and build configuration names are the links to the corresponding overview pages;
-* __Time to start__: the estimated wait duration. Hovering the mouse cursor over the estimated time value shows a tooltip with the following information:
- * the expected start/finish time,
- * the link to the planned agent page.
- * If the current build is a part of a build chain and the builds it depends on are not finished yet, a corresponding note will be displayed. For some builds, like the builds that have never been run before, TeamCity can't estimate possible duration, so the relevant message will be displayed in the tooltip, for example:
-
- 
-
-* __Triggered by__ - a brief description of the [event that triggered the build](configuring-build-triggers.md).
-* __Can run on__ - the number of agents compatible with this build configuration. You can click an agent's name link to open the [Agents page](viewing-build-agent-details.md), or use the down arrow to quickly view the list of compatible agents in the pop-up menu.
-
-### Agent Selection for Queued Build
-
-When there are several idle agents that can run a queued build, TeamCity tries to select the fastest one as follows:
-1. If no builds have previously run on agents, the [CPU rank](viewing-build-agent-details.md#Agent+Summary) is used to select an agent.
-2. If builds have previously run on agents, the estimated build duration for the given build configuration is used to select an agent. The estimate is made based on the heuristics of the latest builds in the history of the build configuration; for estimating, the execution time of the more recent builds has more weight than that of the earlier builds. [Personal](personal-build.md) and [canceled](build-state.md#Canceled%2FStopped+build) builds are not taken into account, neither are any individual builds whose duration differs significantly from the rest of the builds for this build configuration.
-
-### Ordering Build Queue
-
-You can do the following:
-* [reorder](ordering-build-queue.md) the builds in the queue manually.
-* [remove](ordering-build-queue.md#Removing+Builds+From+Build+Queue) build configurations or personal builds from the queue.
-* If you have System Administrator permissions, you can [assign different priorities to build configurations](ordering-build-queue.md#Managing+Build+Priorities), which will affect their position in the queue.
-
-### Pausing/Resuming Build Queue
-
-The build queue can be paused manually or automatically. In this case, the builds are still going to be added to the queue, but they will not be assigned to agents until the queue is unpaused.
-
-Users with the _Enable/disable agent_ permission (included in the [Agent Manager](managing-roles-and-permissions.md#Per-Project+Authorization+Mode) role by default) can manually pause/resume the build queue (since pausing the queue is equivalent to disabling all agents on the server). This action is available in the upper right corner of the __Build Queue__ page.
-
-The build queue can be paused automatically [if the TeamCity server runs out of disk space](teamcity-disk-space-watcher.md). The queue will be automatically resumed when sufficient space is available.
-{product="tc"}
-
-The build queue can be paused automatically if the TeamCity server runs out of disk space. The queue will be automatically resumed when sufficient space is available.
-{product="tcc"}
-
-When the queue is paused, every page in TeamCity will contain a message with information on the reasons for pausing.
-
-
-
- Build Chain
-
-
- Ordering Build Queue
-
-
\ No newline at end of file
diff --git a/topics/build-results-page.md b/topics/build-results-page.md
new file mode 100644
index 000000000..d175f5e60
--- /dev/null
+++ b/topics/build-results-page.md
@@ -0,0 +1,172 @@
+[//]: # (title: Build Results Page)
+[//]: # (auxiliary-id: Build Results Page;Build History)
+
+In TeamCity, all information about a build, whether it is queued, running or finished, is accumulated on its __Build Results__ page. This page can be accessed from the __Build Configuration Home__ page and from various places in the TeamCity UI where a build number or build status appears as a link, when browsing in the __[Home](working-with-build-results.md)__ mode. Some data is accessible only after the build is finished, some details like Changes, Parameters, and Dependencies are also applicable to the build while it is waiting in the queue.
+
+This article gives an overview of the __Build Results__ page of the new TeamCity UI. Most of its features are also available in the classic UI mode.
+
+## Internal Build ID
+
+In the URL of the __Build Results__ page, you can find the parameter `buildId` with a numeric value. This number is the internal build ID uniquely identifying the build in the TeamCity installation. You might need this ID when composing a URL manually. For example, for [REST API](https://www.jetbrains.com/help/teamcity/rest/teamcity-rest-api-documentation.html) requests or when [downloading build artifacts](patterns-for-accessing-build-artifacts.md).
+
+## Build Results Title Panel
+
+The __Build Results__ page contains several tabs, whose set depends on the current build's specifics, and a few common elements:
+
+* Branch selector which displays the branch of the current build. When in __Build Configuration Home__, this selector allows actually filtering the list of displayed builds by a specfic branch.
+* The __Actions__ menu (described [here](build-actions.md)).
+* The __Details__ block: when expanded, shows the main info about the current block.
+* The __Investigation__ widget which lets you quickly assign an [investigation](investigating-and-muting-build-failures.md) of this build or see the details of the open investigation.
+* The __Trends__ widget which shows all the previous builds and their details. Hover a build to see its details.
+
+## Overview Tab
+
+The __Overview__ tab displays general information about the build, such as the build duration, the agent used, trigger, and dependencies. The set of tabs depends on the steps and specifics of the current build. If a build is queued, the tab displays the position of the build in the queue, the time the build is supposed to start, and so on.
+
+
+
+It also shows the diagnostic messages related to the current build's status.
+
+## Changes Tab
+
+The __Changes__ tab displays information about changes in the build, separately for user commits and artifact changes. You can filter changes by their author and display changes made in the build configuration settings.
+
+From the __Changes__ tab, you can:
+* Review all changes included in the build with their corresponding [revisions](revision.md) in version control.
+ * Review changes included in the build that the current build depends on: if the current build configuration has an artifact dependency, and the artifact downloaded in the current build has changed compared to the one downloaded in the previous build of the current configuration, the __Artifact dependencies changes__ node appears displaying the build which was used to download artifact dependencies from, and the changes which were included in that build.
+* [Label the build sources](vcs-labeling.md).
+* [Configure the VCS settings](configuring-vcs-settings.md) of the build configuration (if you have enough permissions).
+
+For each change on this page, you can:
+* Explore the change in details.
+* View which dependent build the changes come from or builds with snapshot dependencies with the "_Show changes from snapshot dependencies_" option enabled.
+* Navigate to the __Change Details__ by clicking a changed file link.
+* [Trigger a custom build](running-custom-build.md) with this change.
+* Download the patch.
+* Download the patch to your IDE.
+* Review the change in an [external change viewer](external-changes-viewer.md), if configured by the administrator.
+ {product="tc"}
+
+You can select to view the modified files by checking the __Show files__ box. Clicking a filename opens the diff viewer.
+
+## Build Log Tab
+
+The graphic build log timeline reflects the duration of each build stage and indicates build problems:
+
+
+
+Click any stage to open the corresponding line of the build log.
+
+More information on build logs in TeamCity is available [here](build-log.md).
+
+## Artifacts Tab
+
+If the build produced [artifacts](build-artifact.md), they all are displayed on the dedicated __Artifacts__ tab.
+
+## Parameters Tab
+
+All system properties and environmental variables which were used by a particular build are listed on the __Parameters__ tab. [Learn more about build parameters](configuring-build-parameters.md).
+
+The __Reported statistic values__ page shows [statistics values](custom-chart.md#Default+Statistics+Values+Provided+by+TeamCity) reported for the build and displays a statistics chart for each of the values on clicking the _View Trend_ icon .
+
+## Dependencies Tab
+
+If a finished build has artifact and/or snapshot dependencies, the __Dependencies__ tab is displayed on the __Build Results__ page. Here you can explore builds whose artifacts and/or sources were used for creating this build (downloaded artifacts) as well as the builds which used the artifacts and/or sources of the current build (delivered artifacts). Additionally, you can view indirect dependencies for the build. That is, for example, if build A depends on build B which depends on builds C and D, then these builds C and D are indirect dependencies for build A.
+
+The __Dependencies__ tab provides three modes of displaying the build dependencies: a visual timeline, structured list, and build chain. Choose the mode that is the most helpful for your current task.
+
+
+
+## Issues Tab
+
+If you have [integration with an issue tracker](integrating-teamcity-with-issue-tracker.md) configured and if there is at least one issue mentioned in the comments for the included changes or in the comments for the build itself, you will see the list of issues related to the current build in the __Issues__ tab.
+
+>If you need to view all the issues related to a build configuration and not just to particular build, you can navigate to the __Issues Log__ tab available on the __Build Configuration Home__ page, where you can see all the issues mapped to the comments or filter the list to particular range of builds.
+
+## Code Coverage Tab
+
+If you have code coverage configured in your build runner, the __Code Coverage__ tab with the full HTML code coverage report will appear.
+
+By clicking the links in the __Coverage Breakdown__ section, you can drill down to display statistics for different scopes: for example, Namespace, Assembly, Method, and Source Code.
+
+## Code Inspection Tab
+
+If configured, the results of a [Code Inspection](configuring-test-reports-and-code-coverage.md#Code+Inspection+in+TeamCity) build step are shown on the __Code Inspection__ tab. Use the left pane to navigate through the inspection results; the filtered inspections are shown in the right pane.
+* Switch from the __Total__ to __Errors__ option, if you are not interested in warnings.
+* Use the scope filter to limit the view to the specific directories. This makes it easier for developers to manage specific code of interest.
+* Use the inspections tree view under the scope filter to display results by specific inspection.
+* Note that TeamCity displays the source code line number that contains the problem. Click it to jump the code in your IDE.
+
+## Duplicates
+
+If your build configuration has Duplicates build runner as one of the build steps, you will see the __Duplicates__ tab in the __Build Results__.
+
+The tab consists of:
+* A list of duplicates found. The __new only__ option enables you to show only the duplicates that appeared in the latest build.
+* A list of files containing these duplicates. Use the left and right arrow buttons to show selected duplicate in the respective pane in the lower part of the tab.
+* Two panes with the source code of the file fragments that contain duplicates.
+* Scope filter in the upper-left corner lists the specific directories that contain the duplicates. This filtering makes it easier for developers to manage the code of interest.
+
+## Tests Tab
+
+The __Tests__ tab allows switching between failed, ignored, and succeeded tests, and use various filters.
+
+For each failed test, you can view its stacktrace, the diff between the expected and actual values, jump to the test history, [assign a team member to investigate its failure](investigating-and-muting-build-failures.md), [open the test in your IDE](installing-tools.md) and/or start fixing it right away.
+
+>Watch our **video tutorial** on how to [use the test report page](https://www.youtube.com/watch?v=LKJjcBJT1k0).
+
+To see a detailed test or investigation history, click __Show test history__ or __Show investigation history__ in its context menu.
+
+Clicking the __Show test history__ link opens the __Test details__ page where you can find following information:
+* The test details, including the test success rate and test's run duration data and graph.
+* A complete test history table containing information about the test's status, its duration, and information on the builds this test was run in.
+
+### Test Duration Graph
+
+The Test Duration graph is useful for comparing the amount of time it takes individual tests to run on the builds of this build configuration.
+
+Test duration results are only available for the builds which are currently in the build history. Once a build has been [cleaned up](teamcity-data-clean-up.md), this data is no longer available.
+
+You can perform the following actions on the Test Duration Graph:
+* Filter out the builds that failed the test by clearing the __Show failed__ option.
+* Calculate the daily average values by selecting the __Average__ option.
+* Click a dot plotted on the graph to jump to the page with the results of the corresponding build.
+* View a build summary in the tooltip of a dot on the graph and navigate to the corresponding __Build Results__ page.
+* Filter information by agents selecting or clearing a particular agent or by clicking __All__ or __None__ links to select or clear all agents.
+
+## Maven Build Info Tab
+
+For each Maven build, a build agent gathers Maven-specific build details to be displayed on the __Maven Build Info__ tab after the build finish. This tab can be useful for build engineers when adjusting build configurations.
+
+## Classic UI Tabs
+
+Other classic UI tabs, not yet reproduced in the new UI, are also available: click __More__ and select the required tab in the list. To view the sections described below, yu can also temporarily switch to the classic UI via the respective toggle in the upper right corner.
+
+### Build History in Classic UI
+
+_Build history_ is a record of the past builds produced by TeamCity. It is displayed as the __Trends__ widget in the new UI and as the menu with links in the classic UI, which is described below.
+
+To view the history of builds in the current configuration, click __previous__ and __next__ links in the upper right corner of __Build Results__. Click __All history__ link to open the __History__ tab.
+
+Navigation menu:
+
+
+
+The __History__ tab:
+
+
+
+### Tests History in Classic UI
+
+The __Tests__ tab of the classic UI differs from the new version and contains a few unique features, such as the ability to download all tests in CSV and pop-up duration graph images. You can temporarily switch to it whenever you need its capabilities.
+
+### Changes in Classic UI
+
+The __Changes__ tab of the classic UI provides advanced filtering capabilities for the list of changes. Enabling __Show graph__ displays the changes as a graph of commits to the VCS roots related to this build.
+
+The graph appears on the left of the list and allows you to get the view of the changes with a variable level of detailing. You can:
+* View the VCS roots which were changed in this build, each of the roots being represented as a bar.
+* Navigate to a graph node to display the VCS root revision number.
+* Click a bar to select a single VCS root. The changes not pertaining to this root are grayed out.
+* If there have been merges between the branches of the repository, the graph displays them. To collapse a bar, navigate to its darker area and click it to hide history of merges. The dotted line will indicate that the bar is expandable.
+* If your VCS root has subrepositories (marked S in the list of changes), navigate to a node in the parent to see which commits in subrepositories are referenced by this revision in the parent.
diff --git a/topics/build-state.md b/topics/build-state.md
index 7f350b554..c27a7a438 100644
--- a/topics/build-state.md
+++ b/topics/build-state.md
@@ -117,7 +117,7 @@ A build was cancelled.
### Canceled/Stopped build
-Stopping a running build results in the build status displayed as cancelled. You can stop a running build from the [__Build Results__](working-with-build-results.md), [__Build Configuration Home__](viewing-build-configuration-details.md) or using the __Stop__ option from the __Actions__ drop-down menu.
+Stopping a running build results in the build status displayed as cancelled. You can stop a running build from the [__Build Results__](working-with-build-results.md), [__Build Configuration Home__](build-configuration-home-page.md) or using the __Stop__ option from the __Actions__ drop-down menu.
When a build is started, the build process calls the runner process and listens to its output. The stop command kills the runner process, then the build process stops.
@@ -230,7 +230,7 @@ A running build can be marked as _Outdated_ if there is a build which contains m
## Failed to Start Builds
-Builds which failed to start, that is did not get to the point of launching the first build step are marked with the  icon. It may be caused by a VCS repository being down when the build starts, or the inability to resolve artifact dependencies and so on. Such build status is often an indication of a configuration error and should usually be addressed by a build engineer rather than a developer.
+Builds which failed to start, that is which did not get to the point of launching the first build step are marked with the  icon. It may be caused by a VCS repository being down when the build starts, or the inability to resolve artifact dependencies and so on. Such build status is often an indication of a configuration error and should usually be addressed by a build engineer rather than a developer.
If such an error occurs, TeamCity:
* doesn't send build failed notification (unless you have subscribed to "the build fails to start" notification)
* doesn't associate pending changes with this build, that is the changes will remain pending, because they were not actually tested
@@ -240,11 +240,11 @@ If such an error occurs, TeamCity:
- Build Configuration Status
+ Build Configuration Status
Change
Change State
- Viewing Your Changes
+ Viewing Your Changes
\ No newline at end of file
diff --git a/topics/build-tag.md b/topics/build-tag.md
deleted file mode 100644
index de144cc44..000000000
--- a/topics/build-tag.md
+++ /dev/null
@@ -1,34 +0,0 @@
-[//]: # (title: Build Tag)
-[//]: # (auxiliary-id: Build Tag)
-
-Build tags are labels that can help you to:
-* organize the history of your builds
-* quickly navigate to the builds marked with a specific tag
-* search for a build with a particular tag
-* create an artifact dependency on a build with a particular tag
-
-You can assign any number of tags for a single build, for example, `EAP` or `release` using the _Edit tags_ dialog by entering several tags separated by any symbol like space, comma, or semicolon.
-
-Clicking a tag filters out all builds in the history: only the builds marked with the tag are displayed. Additionally, you can search for builds with particular tags using the [search field](search.md).
-{product="tc"}
-
-Clicking a tag filters out all builds in the history: only the builds marked with the tag are displayed.
-{product="tcc"}
-
-The TeamCity web UI provides the following ways to tag a particular build:
-* On the __[Build Configuration Home](viewing-build-configuration-details.md)__ page:
- 1. Go to either the __Overview__ or __History__ tab.
- 2. In the build history table, open the context menu of the required build and select __Add tags__ (or __Edit tags__ to modify existing ones).
-* On the __[Build Results](working-with-build-results.md)__ page of the particular build:
- 1. Click __Actions__.
- 2. Select __Tag__ and add/modify the build tags.
-* On the __Queued Build__ page:
- 1. Click __Actions__.
- 2. Select __Tag__ and add/modify the build tags.
-* In the _[Run Custom Build](running-custom-build.md)_ dialog:
- * Go to the __Comments and Tags__ tab and add/modify the build tags.
-* In the _[Pin/Unpin Build](pinned-build.md)_ dialog where you can tag the build in addition to pinning it. For builds with snapshot dependencies, there is an option to pin and tag the build as well as its snapshot dependencies.
-
-Alternatively, you can add and modify build tags using [TeamCity REST API](https://www.jetbrains.com/help/teamcity/rest/manage-finished-builds.html#Manage+Build+Tags).
-
-[//]: # (Internal note. Do not delete. "Build Tagd46e113.txt")
diff --git a/topics/builds-schedule.md b/topics/builds-schedule.md
index a6afd4fa0..d7c76947c 100644
--- a/topics/builds-schedule.md
+++ b/topics/builds-schedule.md
@@ -1,12 +1,12 @@
[//]: # (title: Builds Schedule)
[//]: # (auxiliary-id: Builds Schedule)
-The __Builds Schedule__ page in the administration area of a specific project displays [schedule triggers](configuring-schedule-triggers.md) configured for [build configurations](build-configuration.md) belonging to this project. __Builds Schedule__ for the [Root Project](project.md#Root+Project) displays the list of triggers for the entire TeamCity server.
+The __Builds Schedule__ page in the administration area of a specific project displays [schedule triggers](configuring-schedule-triggers.md) configured for [build configurations](managing-builds.md) belonging to this project. __Builds Schedule__ for the [Root Project](project.md#Root+Project) displays the list of triggers for the entire TeamCity server.
You can conveniently view the available schedule and plan your builds optimizing allocation of dependent hardware/software resources.
From this page it is also possible to [edit](configuring-build-triggers.md), disable or delete the triggers.
-The __Build Schedule__ page also displays the information for [paused build configurations](build-configuration.md#Build+Configuration+State).
+The __Build Schedule__ page also displays the information for [paused build configurations](changing-build-configuration-status.md).
Since TeamCity 2020.1, __Build Schedule__ offers an alternative filter option: to hide triggers with the enabled "_Trigger only if there are pending changes_" option. This helps to quickly find all triggers where this option is disabled if you need to investigate the builds' behavior.
\ No newline at end of file
diff --git a/topics/change-state.md b/topics/change-state.md
index d25a034f6..ebc8911db 100644
--- a/topics/change-state.md
+++ b/topics/change-state.md
@@ -1,6 +1,8 @@
[//]: # (title: Change State)
[//]: # (auxiliary-id: Change State)
+This article lists visual indicators that appear depending on a detected build change, or commit.
+
|
@@ -227,11 +229,11 @@ The change was integrated into a personal build that failed.
- Build Configuration Status
+ Build Configuration Status
Build State
Change
- Viewing Your Changes
+ Viewing Your Changes
\ No newline at end of file
diff --git a/topics/change.md b/topics/change.md
index f310252a6..ffa52ea0e 100644
--- a/topics/change.md
+++ b/topics/change.md
@@ -4,11 +4,11 @@
Any modification of the source code which you introduce. If a change has been committed to the version control system, but not yet included in a build, it is considered pending for a certain build configuration.
TeamCity suggests several ways to view changes:
-* The __[Changes](viewing-your-changes.md)__ page shows the list of changes made by TeamCity users and how they have affected different builds. By default, your own changes are displayed. The page has a user selector enabling you to view changes made by any other TeamCity user the same way you see your own changes.
+* The __[Changes](viewing-user-changes-in-builds.md)__ page shows the list of changes made by TeamCity users and how they have affected different builds. By default, your own changes are displayed. The page has a user selector enabling you to view changes made by any other TeamCity user the same way you see your own changes.
* Pending changes are accessible from the __Projects__ page, build configuration page, or the [build results](working-with-build-results.md) page.
Viewing and analyzing changes involves the following possibilities:
-* Observing actual changes that are already included in the build using the __Changes__ link on the __Projects__ page or on the __Changes__ tab of the __[Build Results](working-with-build-results.md#Changes)__.
+* Observing actual changes that are already included in the build using the __Changes__ link on the __Projects__ page or on the __Changes__ tab of the __[Build Results](build-results-page.md#Changes+Tab)__.
* Observing pending changes on the __Pending Changes__ tab of the __Build Configuration Home__ page.
* Viewing the [revision](revision.md) of the sources corresponding to each change.
* Modifying the change comment in TeamCity, available to project administrators by default (we recommend changing the comment in the VCS as well, for consistency).
@@ -21,7 +21,7 @@ View [possible states of a change](change-state.md).
Revision
- Build Configuration
+ Build Configuration
Investigating and Muting Build Failures
diff --git a/topics/build-configuration.md b/topics/changing-build-configuration-status.md
similarity index 54%
rename from topics/build-configuration.md
rename to topics/changing-build-configuration-status.md
index 146454445..4ce43677d 100644
--- a/topics/build-configuration.md
+++ b/topics/changing-build-configuration-status.md
@@ -1,76 +1,33 @@
-[//]: # (title: Build Configuration)
-[//]: # (auxiliary-id: Build Configuration)
-
-A _build configuration_ is a collection of settings used to start a build and group the sequence of the builds in the UI. Examples of build configurations are _distribution_, _integration tests_, _prepare release distribution_, _"nightly" build_.
-
-A build configuration belongs to a [project](project.md) and contains builds. You can explore details of a build configuration on its [home page](viewing-build-configuration-details.md) and modify its settings on the [editing page](creating-and-editing-build-configurations.md).
-
-It is recommended to have a separate build configuration for each sequence of builds (that is performing a specified task in a dedicated environment). This allows for proper features functioning, like detection of new problems/failed tests, first failed in/fixed in tests status, automatically removed investigations, and so on.
-
-To tackle an increased number of build configurations you can use [build configuration templates](build-configuration-template.md) and project-level [parameters](configuring-build-parameters.md).
-
-This video tutorial illustrates how to work with a build configuration in TeamCity and gives a few extra tips:
-
-
-
-## Build Configuration Settings
-
-Build configuration settings include:
-* [General settings](configuring-general-settings.md)
-* [Version control settings](vcs-root.md), defining how the source code is retrieved from VCS, where it is checked out to, and so on
-* [Build steps](configuring-build-steps.md), that are sequentially run actions: for example, running msbuild, a script, or unit tests
-* [Triggers](configuring-build-triggers.md), which are rules defining when to start a new build
-* [Failure conditions](build-failure-conditions.md) specifying when a build will be marked as failed
-* Additional [build features](adding-build-features.md)
-* Dependencies:
- * for [snapshot dependencies](snapshot-dependencies.md), TeamCity will run all dependent builds on the sources taken at the moment the build they depend on starts
- * for [artifact dependencies](artifact-dependencies.md), before a build is started, all artifacts this build depends on will be downloaded and placed in their configured target locations and then will be used by the build
-* [Parameters](configuring-build-parameters.md) which allow sharing settings
-* Agent requirements specifying whether a [build configuration](build-configuration.md) can run on a particular [build agent](build-agent.md).
-
-
-
-Build configuration settings and build behavior may vary depending on the type of build configuration.
-
-
-## Build Configuration Types
-
-The following build configuration types exist in TeamCity:
-
-* regular build configuration, defining actions and rules to apply to the source code; all the settings above are applicable
-* [deployment build configuration](deployment-build-configuration.md), which deploys artifacts of other builds to some environment
-* [composite build configuration](composite-build-configuration.md), which aggregates results from several other builds combined by snapshot dependencies and presents them in a single place
-
-## Build Configuration State
+[//]: # (title: Changing Build Configuration Status)
+[//]: # (auxiliary-id: Changing Build Configuration Status)
A build configuration is characterized by its state visible in the UI which can be _paused_ or _active_. By default, when created, all configurations are active and can be paused manually as described below or automatically if the project is [archived](archiving-projects.md).
-If a build configuration is _paused_, its [automatic build triggers](configuring-build-triggers.md) are disabled until the configuration is activated. Still, you can start a build of a paused configuration manually or automatically as a part of a [build chain](build-chain.md). Besides, information on paused build configurations is not displayed on the [Changes](viewing-your-changes.md) page.
+If a build configuration is _paused_, its [automatic build triggers](configuring-build-triggers.md) are disabled until the configuration is activated. Still, you can start a build of a paused configuration manually or automatically as a part of a [build chain](build-chain.md). Besides, information on paused build configurations is not displayed on the [Changes](viewing-user-changes-in-builds.md) page.
It is possible to manually pause all or selected build configurations for a project.
-### Pausing Build Configuration
+## Pausing Build Configuration
-To pause a single build configuration, open its __Build Configuration Settings__ or __Home__ page. In the __Actions__ menu, click __Pause__ and enter your comment in the _Pause_ dialog (optional). To remove the builds of the paused build configuration from the [build queue](build-queue.md), check the _Cancel already queued builds_ box. Click __Pause__ to confirm.
+To pause a single build configuration, open its __Build Configuration Settings__ or __Home__ page. In the __Actions__ menu, click __Pause__ and enter your comment in the _Pause_ dialog (optional). To remove the builds of the paused build configuration from the [build queue](working-with-build-queue.md), check the _Cancel already queued builds_ box. Click __Pause__ to confirm.
To activate a paused build configuration, select __Activate__ in the __Actions__ menu.
-### Pausing Several Build Configurations in Project
+## Pausing Several Build Configurations in Project
To pause several build configurations in a project:
1. On the __Project Settings__ page, open the __Actions__ menu and click __Pause/Activate__.
2. In the dialog that opens, select the box next to the project to pause all its build configurations or check the boxes of the configurations selectively: the checked build configurations will be paused.
3. Add an optional comment.
-4. To remove all the builds of the paused configurations from the [build queue](build-queue.md), check the _Cancel already queued builds if build configuration is paused_ box.
-5. Click __Apply__.
+4. To remove all the builds of the paused configurations from the [build queue](working-with-build-queue.md), check the _Cancel already queued builds if build configuration is paused_ box.
+5. Click __Apply__.
To activate several build configurations in a project:
1. On the __Project Settings__ page, open the __Actions__ menu and click __Pause/Activate__.
2. In the dialog that opens, clear the box next to the project to activate all its build configurations or clear the boxes of the configurations selectively: the unselected build configurations will be activated.
3. Add an optional comment.
-4. Click __Apply__.
+4. Click __Apply__.
## Build Configuration Status
@@ -145,7 +102,6 @@ Indicates that someone has started investigating the problem, or already fixed i
_no icon_
-
|
@@ -168,7 +124,7 @@ To see who paused the configuration or to unpause it, click the link next to the
|
-### Status Display for Set of Build Configurations
+## Status Display for Set of Build Configurations
It is possible to filter out the build configurations whose status you want to be displayed in TeamCity or externally.
@@ -183,7 +139,7 @@ To display the status for a set of build configurations __externally__ (on your
* implement a separate page or application which will get the build configuration status via the TeamCity [REST API](https://www.jetbrains.com/help/teamcity/rest/teamcity-rest-api-documentation.html)
-
- Creating and Editing Build Configurations
+
+ Build State Reference
-
+
\ No newline at end of file
diff --git a/topics/changing-build-configuration-type.md b/topics/changing-build-configuration-type.md
new file mode 100644
index 000000000..877ff6a2a
--- /dev/null
+++ b/topics/changing-build-configuration-type.md
@@ -0,0 +1,9 @@
+[//]: # (title: Changing Build Configuration Type)
+[//]: # (auxiliary-id: Changing Build Configuration Type)
+
+A TeamCity build configuration can have one of the following types:
+* Regular
+* [Deployment](deployment-build-configuration.md), which deploys artifacts of other builds to some external environment
+* [Composite](composite-build-configuration.md), which aggregates results from several other builds combined by snapshot dependencies and presents them in a single place
+
+You can change a build configuration's type in its __General Settings__.
\ No newline at end of file
diff --git a/topics/configuring-agent-pools.md b/topics/configuring-agent-pools.md
index 3789e574f..f77168027 100644
--- a/topics/configuring-agent-pools.md
+++ b/topics/configuring-agent-pools.md
@@ -56,7 +56,7 @@ To see the details of a certain pool or its nested [agent](viewing-build-agent-d
Build Agent
- Build Queue
+ Working with Build Queue
Agent Requirements
diff --git a/topics/configuring-agent-requirements.md b/topics/configuring-agent-requirements.md
index a9fbceee9..b1c0e1c18 100644
--- a/topics/configuring-agent-requirements.md
+++ b/topics/configuring-agent-requirements.md
@@ -71,6 +71,6 @@ Note that the __[Agent Requirements](agent-requirements.md)__ page also displays
TeamCity Data Backup
Build Agent
- Build Configuration
+ Build Configuration
\ No newline at end of file
diff --git a/topics/configuring-authentication-settings.md b/topics/configuring-authentication-settings.md
index 57ca2a79f..b95d4421c 100644
--- a/topics/configuring-authentication-settings.md
+++ b/topics/configuring-authentication-settings.md
@@ -114,7 +114,7 @@ Let's imagine that the administrator had the "jsmith" TeamCity username and used
### Special User Accounts
{product="tc"}
-By default, TeamCity has a [Super User](super-user.md) account with maximum permissions and a [Guest User](guest-user.md) with minimal permissions. These accounts have no personal settings such as the __[Changes](viewing-your-changes.md)__ page and Profile information as they are not related to any particular person but rather intended for special use cases.
+By default, TeamCity has a [Super User](super-user.md) account with maximum permissions and a [Guest User](guest-user.md) with minimal permissions. These accounts have no personal settings such as the __[Changes](viewing-user-changes-in-builds.md)__ page and Profile information as they are not related to any particular person but rather intended for special use cases.
## Credentials Authentication Modules
diff --git a/topics/configuring-build-triggers.md b/topics/configuring-build-triggers.md
index eee915e15..7f194e8c8 100644
--- a/topics/configuring-build-triggers.md
+++ b/topics/configuring-build-triggers.md
@@ -1,9 +1,9 @@
[//]: # (title: Configuring Build Triggers)
[//]: # (auxiliary-id: Configuring Build Triggers)
-Once a build configuration is created, builds can be triggered manually by clicking the [Run](running-custom-build.md#Run+Custom+Build+dialog) button or initiated automatically with the help of _triggers_.
+Once a build configuration is created, builds can be triggered manually by clicking the [Run](running-custom-build.md) button or initiated automatically with the help of _triggers_.
-A _build trigger_ is a rule which initiates a new build on certain events. The build is put into the [build queue](build-queue.md) and is started when there are agents available to run it.
+A _build trigger_ is a rule which initiates a new build on certain events. The build is put into the [build queue](working-with-build-queue.md) and is started when there are agents available to run it.
While creating/editing a build configuration, you can configure triggers using the __Triggers__ sections of the __Build Configuration Settings__ page: click __Add new trigger__ and specify the trigger settings. For configuration details on each trigger, refer to the corresponding sections. It is possible to disable a configured build trigger temporarily or permanently using the option in the last column of the trigger list.
diff --git a/topics/configuring-general-settings.md b/topics/configuring-general-settings.md
index 61f842c3d..8840c7dfa 100644
--- a/topics/configuring-general-settings.md
+++ b/topics/configuring-general-settings.md
@@ -1,6 +1,8 @@
[//]: # (title: Configuring General Settings)
[//]: # (auxiliary-id: Configuring General Settings)
+## General Build Configuration Settings
+
When creating a build configuration, specify the following settings:
@@ -156,7 +158,7 @@ Specify additional options for the builds of this build configuration.
### Build Number Format
-In the _Build number format_ field you can specify a pattern which is resolved and assigned to the [build number](build-number.md) on the build start.
+In the _Build number format_ field you can specify a pattern which is resolved and assigned to the build number on the build start.
[//]: # (Internal note. Do not delete. "Configuring General Settingsd79e124.txt")
@@ -218,7 +220,7 @@ Though not required, it is still highly recommended ensuring the build numbers a
-### Artifact Paths
+## Artifact Paths
[Build artifacts](build-artifact.md) are files produced by the build which are stored on TeamCity server and can be downloaded from the TeamCity UI or used as artifact dependencies by other builds. On the __General Settings__ page of the build configuration, you can specify patterns for the files on the agent which will be uploaded to the server after the build.
@@ -259,7 +261,7 @@ The target paths cannot be absolute. Non-relative paths will produce errors duri
>
{type="warning"}
-#### Artifacts Paths Examples
+### Artifacts Paths Examples
* `install.zip` — publish a file named `install.zip` in the build artifacts.
* `dist` — publish the content of the dist directory.
@@ -274,27 +276,27 @@ The target paths cannot be absolute. Non-relative paths will produce errors duri
-### Build Options
+## Build Options
The following options are available to build configurations:
-#### Hanging Build Detection
+### Hanging Build Detection
Select the _Enable hanging build detection_ option to detect probably "hanging" builds. A build is considered to be "hanging" if its run time significantly exceeds the estimated __average run time__ and if the build has not sent any messages since the estimation was exceeded. To properly detect hanging builds, TeamCity has to estimate the average time builds run based on several builds. Thus, if you have a new build configuration, it may make sense to enable this feature after a couple of builds have run, so that TeamCity would have enough information to estimate the average run time.
-#### Allow Triggering Personal Builds
+### Allow Triggering Personal Builds
You can restrict running [personal builds](personal-build.md) by unchecking the __allow triggering personal builds__ option (on by default).
-#### Enable Status Widget
+### Enable Status Widget
This option enables retrieving the status and basic details of the last build in the build configuration without requiring any user authentication. Note that this also allows getting the status of any specific build in the build configuration (however, builds cannot be listed and no other information except the build status (`success/failure/internal error/cancelled`) is available).
The status can be retrieved via the HTML status widget described [below](#HTML+Status+Widget), or via a single icon: with the help of [REST API](https://www.jetbrains.com/help/teamcity/rest/get-build-status-icon.html) or via the __Actions__ menu in __Build Configuration Home__.
-#### HTML Status Widget
+### HTML Status Widget
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.
@@ -345,12 +347,12 @@ It is also possible to show the status of all projects build configurations by r
You can also download and customize the `externalStatus.css` file (for example, you can disable some columns by using `display: none`; see comments in `externalStatus.css`). However, in this case, you must _not_ include the __withCss=true__ parameter, but provide the CSS styles explicitly, preferably in the `` section, instead.
-#### Limit Number of Simultaneously Running Builds
+### Limit Number of Simultaneously Running Builds
Specify the number of builds of the same configuration that can run simultaneously on all agents. This option helps avoid the situation, when all the agents are busy with the builds of a single project. Enter 0 to allow an unlimited number of builds to run simultaneously.
- Build Configuration
+ Build Configuration
\ No newline at end of file
diff --git a/topics/configuring-schedule-triggers.md b/topics/configuring-schedule-triggers.md
index cf3b6d771..ded1404e5 100644
--- a/topics/configuring-schedule-triggers.md
+++ b/topics/configuring-schedule-triggers.md
@@ -49,8 +49,8 @@ If the "_[Show changes from snapshot dependencies](configuring-vcs-settings.md#s
A schedule trigger can watch a build in any specified build configuration and trigger a build only if the watched build has changed since the previous triggering. You can select which build to watch:
* Last finished build
* Last successful build
-* Last [pinned build](pinned-build.md)
-* Last finished build with a specified [build tag](build-tag.md)
+* Last [pinned build](build-actions.md#Pin+Build)
+* Last finished build with a specified [build tag](build-actions.md#Add+Tags+to+Build)
If the trigger detects a new build that satisfies the selected characteristic in the watched configuration, it queues a new build in own configuration.
@@ -76,7 +76,7 @@ Use this option to run a build simultaneously on all agents that are enabled and
### Build Queue Optimization Settings
-By default, TeamCity [optimizes the build queue](build-queue.md#Build+Queue+Optimization+by+TeamCity): already queued build can be replaced with an already started build or a more recent queued build. You can disable this default behavior by unchecking the corresponding box.
+By default, TeamCity [optimizes the build queue](working-with-build-queue.md#Build+Queue+Optimization+by+TeamCity): already queued build can be replaced with an already started build or a more recent queued build. You can disable this default behavior by unchecking the corresponding box.
### Branch Filter
diff --git a/topics/configuring-test-reports-and-code-coverage.md b/topics/configuring-test-reports-and-code-coverage.md
index 6a1fc2e34..5232125e0 100644
--- a/topics/configuring-test-reports-and-code-coverage.md
+++ b/topics/configuring-test-reports-and-code-coverage.md
@@ -18,7 +18,7 @@ TeamCity comes with code analysis tools capable of inspecting your source code o
The following inspections tools are bundled with TeamCity:
* [Inspections (IntelliJ IDEA)](inspections.md): runs code analysis based on [IntelliJ IDEA inspections](http://www.jetbrains.com/idea/documentation/inspections.jsp). More than 600 Java, HTML, CSS, JavaScript inspections are performed by this runner.
* [Inspections (ReSharper)](inspections-resharper.md): gathers results of [JetBrains ReSharper](http://www.jetbrains.com/resharper) [Code Analysis](http://www.jetbrains.com/resharper/webhelp/Code_Analysis__Index.html) in your C#, VB.NET, XAML, XML, ASP.NET, JavaScript, CSS, and HTML code.
- Inspection results are reported in the __[Code Inspection](working-with-build-results.md#Code+Inspection+Results)__ tab of the __Build Results__ page.
+ Inspection results are reported in the __[Code Inspection](build-results-page.md#Code+Inspection+Tab)__ tab of the __Build Results__ page.
TeamCity can also be [integrated with external reporting tools](how-to.md#Integrate+with+Build+and+Reporting+Tools).
diff --git a/topics/configuring-vcs-settings.md b/topics/configuring-vcs-settings.md
index d605af8bb..209859ad3 100644
--- a/topics/configuring-vcs-settings.md
+++ b/topics/configuring-vcs-settings.md
@@ -7,7 +7,7 @@ A Version Control System (VCS) is a system for tracking the revisions of the pro
A Version Control System (VCS) is a system for tracking the revisions of the project source files. It is also known as SCM (source code management) or a revision control system. The following VCSs are supported by TeamCity out-of-the-box: [Git](git.md), [Subversion](subversion.md), [Mercurial](mercurial.md), [Perforce](perforce.md), [Azure DevOps](azure-devops.md).
{product="tcc"}
-Connection to a version control system is defined by a TeamCity [VCS root](vcs-root.md). A [project](project.md) or a [build configuration](build-configuration.md) in TeamCity can have one or more VCS roots attached; a build configuration can also define the workspace for the builds via other checkout options like [Checkout Rules](vcs-checkout-rules.md).
+Connection to a version control system is defined by a TeamCity [VCS root](vcs-root.md). A [project](project.md) or a [build configuration](managing-builds.md) in TeamCity can have one or more VCS roots attached; a build configuration can also define the workspace for the builds via other checkout options like [Checkout Rules](vcs-checkout-rules.md).
TeamCity always monitors the repositories from the server-side to detect changes and display them in the UI. Depending on the specified [VCS Checkout Mode](vcs-checkout-mode.md) the actual repository checkout can also happen on the agent-side.
diff --git a/topics/configuring-vcs-triggers.md b/topics/configuring-vcs-triggers.md
index 6869026c4..bd1530757 100644
--- a/topics/configuring-vcs-triggers.md
+++ b/topics/configuring-vcs-triggers.md
@@ -253,7 +253,7 @@ When changes are merged / fast-forwarded from one branch to another, strictly sp
The __Build Customization__ tab of a trigger's settings allows configuring custom parameters of builds started by this trigger. Similarly to the [Run Custom Build](running-custom-build.md) dialog, it lets you override values of [build parameters](configuring-build-parameters.md) and choose if the [checkout directory](build-checkout-directory.md) should be cleaned before the build.
-On this tab, you can customize the value of any [parameter](configuring-build-parameters.md) used in the current [build configuration](build-configuration.md). Or, you can add a new parameter, and it will be available only in builds started by this trigger. If the current build has [snapshot dependencies](snapshot-dependencies.md) on other builds, such a parameter can also be used to [override a certain property](predefined-build-parameters.md#Overriding+Dependency+Parameters) of a dependency build configuration: use the `reverse.dep..` syntax for this.
+On this tab, you can customize the value of any [parameter](configuring-build-parameters.md) used in the current [build configuration](managing-builds.md). Or, you can add a new parameter, and it will be available only in builds started by this trigger. If the current build has [snapshot dependencies](snapshot-dependencies.md) on other builds, such a parameter can also be used to [override a certain property](predefined-build-parameters.md#Overriding+Dependency+Parameters) of a dependency build configuration: use the `reverse.dep..` syntax for this.
>This functionality gets more effective if you combine it with the [build step execution conditions](build-step-execution-conditions.md). You just need to add a parameter-based condition to a step and then configure two triggers: one will run builds with this step (when the condition is satisfied) and one — without it. A popular use case is to run a limited number of tests in regular builds but a full set of tests in a nightly build, when the server load is the lowest.
diff --git a/topics/configuring-your-user-profile.md b/topics/configuring-your-user-profile.md
index 16cdf010b..796d32370 100644
--- a/topics/configuring-your-user-profile.md
+++ b/topics/configuring-your-user-profile.md
@@ -49,7 +49,7 @@ By default, TeamCity uses your login name as the VCS username. Click __Edit__ to
These settings are not used for authentication for the particular VCS, and so on.
These settings enable you to:
-* track your changes status on the [Changes](viewing-your-changes.md),
+* track your changes status on the [Changes](viewing-user-changes-in-builds.md),
* highlight such builds on the Projects page if the appropriate [option is selected](#Customizing+UI),
* notify you on such builds when the __Builds affected by my changes__ option is selected in [notifications settings](adding-notification-rules.md#What+Will+Be+Watched).
@@ -72,7 +72,7 @@ In __Your Profile | General__, you can customize the following UI settings:
* Highlight my changes and investigations: Select to highlight builds that include your changes (changes committed by a user with the VCS username provided in the [Version Control Username Settings](#Managing+Version+Control+Username+Settings) section) and problems you were assigned to investigate on the __Projects__ page, __Project Home__ page, __Build Configuration Home__ page.
* Show date/time in my timezone: Check the option, if you want TeamCity to automatically detect your time zone and show the date and time (for example, build start, VCS change time, and so on) according to it.
* Show all personal builds
-* Add builds manually triggered by you to your [favorites](favorite-build.md).
+* Add builds manually triggered by you to your [favorites](build-actions.md#Add+Build+to+Favorites).
## Viewing your Roles and Permissions
@@ -93,7 +93,7 @@ Since version 2021.2, users can upload their avatars in the user profile. The av
Roles and Permissions
- Viewing Your Changes
+ Viewing Your Changes
Subscribing to Notifications
\ No newline at end of file
diff --git a/topics/continuous-integration-with-teamcity.md b/topics/continuous-integration-with-teamcity.md
index e9797b8eb..63263693f 100644
--- a/topics/continuous-integration-with-teamcity.md
+++ b/topics/continuous-integration-with-teamcity.md
@@ -91,7 +91,7 @@ __TeamCity Server__
|
-The __server__ itself __does not run either builds or tests:__ the server's job is to monitor all the connected build agents, distribute [queued builds](build-queue.md) to the agents based on compatibility requirements, and report the results. All information on the build results (build history and all the build-associated data except for artifacts and build logs), VCS changes, agents, build queue, user accounts and user permissions, and so on, are stored in a database.
+The __server__ itself __does not run either builds or tests:__ the server's job is to monitor all the connected build agents, distribute [queued builds](working-with-build-queue.md) to the agents based on compatibility requirements, and report the results. All information on the build results (build history and all the build-associated data except for artifacts and build logs), VCS changes, agents, build queue, user accounts and user permissions, and so on, are stored in a database.
>It is possible for the server and an agent to coexist on the same computer, but for production purposes, we recommend installing them on different machines for a number of reasons, the server performance being the most important.
>
@@ -108,7 +108,7 @@ __Project__
|
-A TeamCity project corresponds to a software project or a specific version/release of a software project. A project is a collection of _[build configurations](build-configuration.md)_.
+A TeamCity project corresponds to a software project or a specific version/release of a software project. A project is a collection of _[build configurations](managing-builds.md)_.
|
@@ -182,7 +182,7 @@ __Build__
A CI/CD job executed on an agent. Consists of one or more steps that can do any service task: compile, test, deploy, produce reports, and so on.
-The term _build_ can refer to both the actual process of building and the result of building. After the build process is triggered, it is put into the _[build queue](build-queue.md)_ and is started when there are agents available to run it. After the build is finished, the build agent sends _[build artifacts](build-artifact.md)_ to the server.
+The term _build_ can refer to both the actual process of building and the result of building. After the build process is triggered, it is put into the _[build queue](working-with-build-queue.md)_ and is started when there are agents available to run it. After the build is finished, the build agent sends _[build artifacts](build-artifact.md)_ to the server.
diff --git a/topics/creating-and-editing-build-configurations.md b/topics/creating-and-editing-build-configurations.md
index a2bd25c6d..5b9541853 100644
--- a/topics/creating-and-editing-build-configurations.md
+++ b/topics/creating-and-editing-build-configurations.md
@@ -1,12 +1,24 @@
[//]: # (title: Creating and Editing Build Configurations)
[//]: # (auxiliary-id: Creating and Editing Build Configurations)
-This page details creating build configurations via the TeamCity UI.
+This section contains articles on how to create and configure build configurations via the TeamCity UI.
->Build configurations can also be created via [TeamCity REST API](https://www.jetbrains.com/help/teamcity/rest/get-build-details.html#Get+Specific+Builds) and as a versioned [Kotlin DSL code](storing-project-settings-in-version-control.md).
+A _build configuration_ is a collection of settings used to start a build and group the sequence of the builds in the UI. Examples of build configurations are _distribution_, _integration tests_, _prepare release distribution_, _"nightly" build_.
+A build configuration belongs to a [project](project.md) and contains builds. You can explore details of a build configuration on its [Home page](build-configuration-home-page.md) and modify its settings on the [Settings page](creating-and-editing-build-configurations.md).
+It is recommended to have a separate build configuration for each sequence of builds (that is performing a specified task in a dedicated environment). This allows for proper features functioning, like detection of new problems/failed tests, first failed in/fixed in tests status, automatically removed investigations, and so on.
+
+To tackle an increased number of build configurations you can use [build configuration templates](build-configuration-template.md) and project-level [parameters](configuring-build-parameters.md).
+
+This video tutorial illustrates how to work with a build configuration in TeamCity and gives a few extra tips:
+
+
+
+>Build configurations can also be created via [TeamCity REST API](https://www.jetbrains.com/help/teamcity/rest/get-build-details.html#Get+Specific+Builds) and as a versioned [Kotlin DSL code](storing-project-settings-in-version-control.md).
+
## Where to Create Build Configuration
To find the build configuration creation wizard:
@@ -102,7 +114,27 @@ The settings specified in the template cannot be edited in a configuration creat
You can view all build configurations of a project on the __Project Overview__ page. By default, they are listed in the alphabetical order, but administrators can [customize this order](ordering-projects-and-build-configurations.md).
-## Configuring Settings
+## Build Configuration Settings
+
+Build configuration settings include:
+* [General settings](configuring-general-settings.md)
+* [Version control settings](vcs-root.md), defining how the source code is retrieved from VCS, where it is checked out to, and so on
+* [Build steps](configuring-build-steps.md), that are sequentially run actions: for example, running msbuild, a script, or unit tests
+* [Triggers](configuring-build-triggers.md), which are rules defining when to start a new build
+* [Failure conditions](build-failure-conditions.md) specifying when a build will be marked as failed
+* Additional [build features](adding-build-features.md)
+* Dependencies:
+ * for [snapshot dependencies](snapshot-dependencies.md), TeamCity will run all dependent builds on the sources taken at the moment the build they depend on starts
+ * for [artifact dependencies](artifact-dependencies.md), before a build is started, all artifacts this build depends on will be downloaded and placed in their configured target locations and then will be used by the build
+* [Parameters](configuring-build-parameters.md) which allow sharing settings
+* Agent requirements specifying whether a [build configuration](managing-builds.md) can run on a particular [build agent](build-agent.md).
+
+
+
+Build configuration settings and build behavior may vary depending on the type of build configuration.
+
+
+### Configuring Settings
When you select a build configuration from the list of build configurations, TeamCity displays the __Build Configuration Home__ page where you can preview its recent build results. To access the build configuration's settings, click __Edit Configuration Settings__ in the upper right corner of the screen.
@@ -124,13 +156,14 @@ We recommend considering this aspect when granting users the permissions mention
## Actions in Build Configuration Settings
-Use the __Actions__ menu, located in the upper right corner of the settings screen, to
-* [pause/activate a build configuration](build-configuration.md#Pausing+Build+Configuration)
-* [copy/move/delete a build configuration](copy-move-delete-build-configuration.md)
-* [attach a build configuration to a template](build-configuration-template.md#Associating+build+configurations+with+templates)
-* [extract a template from a build configuration](build-configuration-template.md#Creating+build+configuration+template)
-* [extract a meta-runner from a build configuration](working-with-meta-runner.md#Extracting+and+Using+Meta-Runner)
-* [attach a history to a build configuration](kotlin-dsl.md#Restoring+Build+History+After+ID+Change)
+Use the __Actions__ menu, located in the upper right corner of the settings screen, to:
+* [Pause/activate a build configuration](changing-build-configuration-status.md).
+* [Copy/move/delete a build configuration](copy-move-delete-build-configuration.md).
+* [Attach a build configuration to a template](build-configuration-template.md#Associating+build+configurations+with+templates).
+* [Extract a template from a build configuration](build-configuration-template.md#Creating+build+configuration+template).
+* [Extract a meta-runner from a build configuration](working-with-meta-runner.md#Extracting+and+Using+Meta-Runner).
+* [Attach a history to a build configuration](kotlin-dsl.md#Restoring+Build+History+After+ID+Change).
+
diff --git a/topics/creating-and-editing-projects.md b/topics/creating-and-editing-projects.md
index 54737633f..847eabb74 100644
--- a/topics/creating-and-editing-projects.md
+++ b/topics/creating-and-editing-projects.md
@@ -265,7 +265,7 @@ Use the corresponding item from the __Actions__ menu in the upper right corner o
Projects can be copied and moved to another project by project administrators.
-A copy duplicates all the settings, [subprojects](project.md#Project+Hierarchy), [build configurations](build-configuration.md), and [templates](build-configuration-template.md) of the original project, but no data related to builds is preserved. The copy is created with the empty [build history](build-history.md) and no [statistics](statistic-charts.md).
+A copy duplicates all the settings, [subprojects](project.md#Project+Hierarchy), [build configurations](managing-builds.md), and [templates](build-configuration-template.md) of the original project, but no data related to builds is preserved. The copy is created with the empty [build history](build-results-page.md#Build+History+in+Classic+UI) and no [statistics](statistic-charts.md).
You can copy a project into the same or another parent.
@@ -294,7 +294,7 @@ Before moving the project, consider the following:
To move a project, use the corresponding item from the __Actions__ menu in the upper right corner of the __Project Settings__ page or the _More_ button  next to the project on the parent __Project Settings__ page.
-When moving a project, TeamCity preserves all its settings, [subprojects](project.md#Project+Hierarchy), [build configurations](build-configuration.md)/[templates](build-configuration-template.md), and associated data, as well as the [build history](build-history.md).
+When moving a project, TeamCity preserves all its settings, [subprojects](project.md#Project+Hierarchy), [build configurations](managing-builds.md)/[templates](build-configuration-template.md), and associated data, as well as the [build history](build-results-page.md#Build+History+in+Classic+UI).
### Archiving Project
@@ -313,7 +313,7 @@ Care must be taken when performing this action. Modifying the ID will change all
### Pausing / Activating Triggers
-You can [pause triggers](build-configuration.md#Pausing+Several+Build+Configurations+in+Project) for all or selected build configurations of a project. Use the corresponding item from the __Actions__ menu in the upper right corner of the __Project Settings__ page or the _More_ button  next to the project on the parent __Project Settings__ page.
+You can [pause triggers](changing-build-configuration-status.md#Pausing+Several+Build+Configurations+in+Project) for all or selected build configurations of a project. Use the corresponding item from the __Actions__ menu in the upper right corner of the __Project Settings__ page or the _More_ button  next to the project on the parent __Project Settings__ page.
### Exporting Project
diff --git a/topics/creating-and-managing-users.md b/topics/creating-and-managing-users.md
index 62f84331f..38ecbbb40 100644
--- a/topics/creating-and-managing-users.md
+++ b/topics/creating-and-managing-users.md
@@ -47,7 +47,7 @@ This tab allows viewing and editing default usernames for different VCSs used by
Multiple usernames are supported for a VCS root type and for a separate VCS root: several newline-separated values can be used for each VCS username.
The names set here will be used to:
-* show builds with changes committed by a user with such a VCS username on the [Changes](viewing-your-changes.md) page
+* show builds with changes committed by a user with such a VCS username on the [Changes](viewing-user-changes-in-builds.md) page
* highlight such builds on the Projects page if the appropriate [option is selected](configuring-your-user-profile.md#Customizing+UI),
* notify the user on such builds when the __Builds affected by my changes__ option is selected in [notifications settings](adding-notification-rules.md#What+Will+Be+Watched).
diff --git a/topics/detaching-build-from-agent.md b/topics/detaching-build-from-agent.md
index 06360d945..827b90e98 100644
--- a/topics/detaching-build-from-agent.md
+++ b/topics/detaching-build-from-agent.md
@@ -23,7 +23,7 @@ To perform a request, it needs to provide:
* [build-level authentication](artifact-dependencies.md#Build-level+authentication) credentials specified as [build system properties](configuring-build-parameters.md):
* username: `%\system.teamcity.auth.userId%`
* password: `%\system.teamcity.auth.password%`
-* [build ID](working-with-build-results.md#Internal+Build+ID): `%\teamcity.build.id%`
+* [build ID](build-results-page.md#Internal+Build+ID): `%\teamcity.build.id%`
* TeamCity server URL: `%\teamcity.serverUrl%`
An agent should send these parameters to the external software in advance, before being released.
diff --git a/topics/difference-viewer.md b/topics/difference-viewer.md
index e291606cb..9e477e664 100644
--- a/topics/difference-viewer.md
+++ b/topics/difference-viewer.md
@@ -1,7 +1,7 @@
[//]: # (title: Difference Viewer)
[//]: # (auxiliary-id: Difference Viewer)
-TeamCity Difference Viewer allows reviewing the differences between two versions of a file modified in the source control and navigating between these differences. You can access the viewer from almost any place in the TeamCity UI where the changes' lists appear, for example, the __Projects__ page, the __Build Configuration Home__ page, or the __[Changes](working-with-build-results.md#Changes)__ tab of the build results page. Comparing images in the GIF, PNG, or JPG file formats are also supported.
+TeamCity Difference Viewer allows reviewing the differences between two versions of a file modified in the source control and navigating between these differences. You can access the viewer from almost any place in the TeamCity UI where the changes' lists appear, for example, the __Projects__ page, the __Build Configuration Home__ page, or the __[Changes](build-results-page.md#Changes+Tab)__ tab of the build results page. Comparing images in the GIF, PNG, or JPG file formats are also supported.
Clicking the name of a modified file opens the viewer (the left part shows the file in its former state, and the right one — the modified file):
@@ -19,6 +19,6 @@ If you want to switch to your IDE and explore a change in detail, click __Open i
Project
- Build Configuration
+ Build Configuration
\ No newline at end of file
diff --git a/topics/disk-usage.md b/topics/disk-usage.md
index be8849416..c677788ed 100644
--- a/topics/disk-usage.md
+++ b/topics/disk-usage.md
@@ -16,7 +16,7 @@ The report contains information on the total free disk space and the amount of s
The default location for these directories is `<[TeamCity Data Directory](teamcity-data-directory.md)>/system`. If build logs and artifacts directories are [located on different disks](teamcity-data-directory.md#Recommendations+as+to+choosing+Data+Directory+Location), free space is reported for each of the disks.
{product="tc"}
-The report also displays [pinned builds](pinned-build.md), if available, and the space taken by their logs and artifacts.
+The report also displays [pinned builds](build-actions.md#Pin+Build), if available, and the space taken by their logs and artifacts.
By default, the report displays data on the builds run from build configurations grouped by projects. You can choose to view the ungrouped list of build configurations or to show archived projects if required using the corresponding checkboxes. You can sort the information by clicking the column name.
diff --git a/topics/docker-wrapper.md b/topics/docker-wrapper.md
index bffdd3814..847791902 100644
--- a/topics/docker-wrapper.md
+++ b/topics/docker-wrapper.md
@@ -12,6 +12,7 @@ The extension is available for the following [build runners](build-runner.md):
* [Python](python.md)
* [PowerShell](powershell.md)
* [C# Script](c-script.md)
+* [Node.js](nodejs.md)
Each of the supported runners has the dedicated Docker settings section.
@@ -107,7 +108,7 @@ By default, a TeamCity agent uses the `busybox` image from Docker Hub to run the
## Environment Variables Handling
-TeamCity passes environment variables from the [build configuration](build-configuration.md) into the Docker process, but it does not pass environment variables from the [build agent](build-agent.md), as they may not be relevant to the Docker container environment. The list of the passed environment variables can be seen in the [Verbose mode](build-log.md#Viewing+Build+Log) in the build log.
+TeamCity passes environment variables from the [build configuration](managing-builds.md) into the Docker process, but it does not pass environment variables from the [build agent](build-agent.md), as they may not be relevant to the Docker container environment. The list of the passed environment variables can be seen in the [Verbose mode](build-log.md#Viewing+Build+Log) in the build log.
## Setting Image Entrypoint
diff --git a/topics/external-changes-viewer.md b/topics/external-changes-viewer.md
index 18f82ce58..b733d87f5 100644
--- a/topics/external-changes-viewer.md
+++ b/topics/external-changes-viewer.md
@@ -12,6 +12,6 @@ When the configuration file is created, links to the external viewer (
-* __[Changes](working-with-build-results.md#Changes)__ tab of the build results page
+* __[Changes](build-results-page.md#Changes+Tab)__ tab of the Build Results page
* __Change Details__ page available by clicking the link when hovering over the changes on the __Overview__ and __Change Log__ tabs for a project and build configurations and on the __Changes__ tab of the __Build Results__ page
* [TeamCity file diff page](difference-viewer.md)
\ No newline at end of file
diff --git a/topics/favorite-build.md b/topics/favorite-build.md
deleted file mode 100644
index e7aa427ce..000000000
--- a/topics/favorite-build.md
+++ /dev/null
@@ -1,30 +0,0 @@
-[//]: # (title: Favorite Build)
-[//]: # (auxiliary-id: Favorite Build)
-
-To easily access builds you want to monitor, you can mark them as favorite.
-
-[//]: # (Internal note. Do not delete. "Favorite Buildd142e4.txt")
-
-## Adding Builds to Favorites
-
-To manually add a build to your favorites, use the appropriate option from the __Actions__ menu on the __[Build Results](working-with-build-results.md)__ page. Your favorite build will be marked with a star symbol .
-
-Any of your manually triggered builds and [personal builds](personal-build.md) can be added to your favorites automatically if you enable the corresponding setting in your [user profile settings](configuring-your-user-profile.md).
-
-You can also add a custom build to favorites by checking the [corresponding box](running-custom-build.md#Comment+and+Tags).
-
-## Viewing Your Favorites
-
-To view your favorites, in the top right corner of the TeamCity web UI, click the arrow next to your username, and select __My Favorite Builds__.
-
-You can also configure notifications on your favorite builds using the appropriate link on this page.
-
-## Configuring Notifications on Your Favorite Builds
-
-When [subscribing to notifications](adding-notification-rules.md), you can limit notifications on the selected watched projects or build configurations to your favorite builds only.
-
-## Removing Builds from Favorites
-
-To remove builds from favorites:
-* On the __Favorite Builds__ or __[Build Results](working-with-build-results.md)__ page, click the star symbol .
-* Alternatively, on the __[Build Results](working-with-build-results.md)__ page, use the __Remove Builds from favorites__ option from the __Actions__ menu.
diff --git a/topics/first-failure.md b/topics/first-failure.md
deleted file mode 100644
index 04d268ab8..000000000
--- a/topics/first-failure.md
+++ /dev/null
@@ -1,15 +0,0 @@
-[//]: # (title: First Failure)
-[//]: # (auxiliary-id: First Failure)
-
-TeamCity displays the "_First Failure_" build for some tests.
-
-This is the build where TeamCity detected the first failure of this test for the same [build configuration](build-configuration.md), which means that starting from the current build, TeamCity goes back throughout the build history to find out when this test failed for the first time. Builds without this test are skipped, and if a successful test run was found, the search stops.
-Here, _back throughout the history_ means that builds are analyzed with regard to changes as detected by TeamCity; as a result, [history builds](history-build.md) will be processed correctly.
-
-A test which runs several times within a single build is counted as one test (that is all invocations of the same test are counted as one).
-
-
-
- Already Fixed In
-
-
\ No newline at end of file
diff --git a/topics/fxcop.md b/topics/fxcop.md
index 477dcbfec..c104fc9ff 100644
--- a/topics/fxcop.md
+++ b/topics/fxcop.md
@@ -221,7 +221,7 @@ Check the box to fail a build on the specified analysis errors. Click [build fai
## Using Service Messages
-If you prefer to call the FxCop tool directly from the script, not as a build runner, you can use the `importData` [service messages](service-messages.md) to import an XML file generated by [the FxCopCmd tool](http://msdn.microsoft.com/en-us/library/bb429474(VS.80).aspx) into TeamCity. In this case the FxCop tool results will appear in the [Code Inspection tab](working-with-build-results.md#Code+Inspection+Results) of the __Build Results__ page.
+If you prefer to call the FxCop tool directly from the script, not as a build runner, you can use the `importData` [service messages](service-messages.md) to import an XML file generated by [the FxCopCmd tool](http://msdn.microsoft.com/en-us/library/bb429474(VS.80).aspx) into TeamCity. In this case the FxCop tool results will appear in the __[Code Inspection](build-results-page.md#Code+Inspection+Tab)__ tab of the __Build Results__ page.
The [service message](service-messages.md) format is described below:
diff --git a/topics/glossary.md b/topics/glossary.md
index 66fd1b6d5..f3af7b52e 100644
--- a/topics/glossary.md
+++ b/topics/glossary.md
@@ -41,7 +41,7 @@ Authentication module
## B
Build
-: A process that performs a certain CI/CD job. Most builds comprise multiple sequential steps executing their own granular actions. A build is run based on the settings specified in its build configuration.
+: A process that performs a certain CI/CD job. Most builds comprise multiple sequential steps executing their own granular actions. A build is executed according to the settings specified in its build configuration.
Build agent
: A piece of software which listens for the commands from the TeamCity server and starts the actual build process. Agents can be installed in the customer's environment or run on-demand in the cloud.
@@ -74,7 +74,12 @@ Build log
: An enhanced console output of a build. It is represented by a structured list of the events which took place during the build. Generally, it includes entries on TeamCity-performed actions and the output of the processes launched during the build. TeamCity captures the processes output and stores it in an internal format that allows for hierarchical display.
Build number
-: A string identifier composed according to the pattern specified in the build configuration settings. This number is displayed in the UI and passed into the build as a [predefined property](predefined-build-parameters.md). It is often used for passing and downloading artifacts.
+: A string identifier composed according to the pattern specified in the build configuration settings. This number is displayed in the UI and passed into the build as a [predefined parameter](predefined-build-parameters.md). It can be:
+* [used to download artifacts](patterns-for-accessing-build-artifacts.md#Obtaining+Artifacts)
+* [referenced as a property](predefined-build-parameters.md)
+* [shared for builds connected by a dependency](how-to.md#Share+the+Build+number+for+Builds+in+a+Chain+Build)
+* [used in artifact dependencies](artifact-dependencies.md)
+* [set by a service message](service-messages.md#Reporting+Build+Number)
Build queue
: A list of builds that were [triggered](configuring-build-triggers.md) and are waiting to be started. TeamCity will distribute them to compatible build agents as soon as these agents become idle. A queued build is assigned to an agent at the moment it is started on the agent; no preassignment is made while the build is waiting in the build queue.
@@ -128,6 +133,9 @@ Continuous integration
Continuous integration is also associated with _Extreme Programming_ and other _agile_ software development practices.
Following the principles of _Continuous Integration_, TeamCity allows users to monitor the software development process of the company, while improving communication and facilitating the integration of changes without breaking any established practices.
+Custom build run
+* A standalone build whose settings have been adjusted compared to its build configuration. Such a build can be initiated from a context menu next to the __Run__ button.
+
## D
Dependent build
@@ -176,7 +184,7 @@ Personal build
: A build that is executed out of the common build sequence. Typically, it uses the changes not yet committed into the version control. This allows developers to run their newly added functionality in a real environment without modifying the project code in the VCS. Personal builds are usually initiated from an IDE via the Remote Run procedure.
Pinned build
-: A build that is prevented from being removed during a [clean-up](teamcity-data-clean-up.md) procedure.
+: A build that is prevented from being removed during a scheduled [clean-up](teamcity-data-clean-up.md).
Pre-tested commits
: An approach that prevents committing defective code into a build, so the entire team's process is not affected. [These diagrams](http://www.jetbrains.com/teamcity/features/delayed_commit.html) illustrate the TeamCity approach to pre-tested commits.
@@ -202,7 +210,7 @@ Root project
: A default project at the top of the project hierarchy. Its settings are available to all the other projects on the server.
Run configuration policy
-: A policy that allows selecting specific build configurations you want a build agent to run. By default, build agents run all compatible build configurations, and this is not always desirable — in this case, this policy lets you limit the allowed set in each agent's details.
+: A policy that allows selecting specific build configurations you want a build agent to run. By default, build agents run all compatible build configurations, and this is not always desirable — in this case, this policy lets you limit the allowed set in each agent's details. The run configuration policy settings are located in __[Agents Details](viewing-build-agent-details.md) | Compatible configurations__.
## S
diff --git a/topics/history-build.md b/topics/history-build.md
index d8a775241..9457e87f8 100644
--- a/topics/history-build.md
+++ b/topics/history-build.md
@@ -6,7 +6,7 @@ A _history build_ is a build that starts after a build with more recent changes.
[//]: # (Internal note. Do not delete. "History Buildd159e7.txt")
A build may become a history build in the following situations:
-* If you initiate a build on particular changes manually using the _[Run Custom Build ](running-custom-build.md)_ dialog.
+* If you initiate a build on particular changes manually using the _[Run Custom Build](running-custom-build.md)_ dialog.
* If you have a [VCS trigger](configuring-vcs-triggers.md) with a quiet period set. During this quiet period, a different user can start a build with more recent changes. In this case, your automatically triggered build will have an older source revision when it starts, and will be marked as a history build.
* If there are several builds of the same configuration in the build queue and they have fixed revisions (for example, they are part of a [build chain](build-chain.md)). If someone manually reorders these builds, the build with fewer changes can be started first.
@@ -20,8 +20,7 @@ As the history build does not reflect the current state of the sources, the foll
- Build History
- Build Queue
+ Working with Build Queue
Triggering a Custom Build
diff --git a/topics/how-to-configure-cicd-for-jetbrains-space.md b/topics/how-to-configure-cicd-for-jetbrains-space.md
index 9d01c917b..022bd0684 100644
--- a/topics/how-to-configure-cicd-for-jetbrains-space.md
+++ b/topics/how-to-configure-cicd-for-jetbrains-space.md
@@ -90,7 +90,7 @@ You will notice the new button: __From JetBrains Space__. Its name depends on th
>If you get the _OAuth 2.0 Error_, this might mean that the _Redirect URI_ has not been configured properly in Step 1 of the preliminary setup. Make sure to [revise it](#redirect-uri). Note that Space supports only HTTPS connection.
3. The project creation wizard will display a list of all Space projects your user has access to. Choose a repository and wait until TeamCity verifies the connection settings.
4. Now it's time to configure the main settings of the new project and its [VCS root](vcs-root.md). You can always adjust them later.
- * _Project name_ and the name of its first [build configuration](build-configuration.md).
+ * _Project name_ and the name of its first [build configuration](managing-builds.md).
* _VCS root_: (read-only) matches the URL of a repository you choose in Step 3.
* _Default branch_: `refs/heads/main`, or another branch of your choice. Remember to keep `refs/heads` and change only the branch name.
* _Branch specification_: if you want to run builds on other branches apart from the default one, this setting allows extending the scope of the VCS root to monitor these branches as well. TeamCity uses a [special format or branch specification rules](working-with-feature-branches.md) for this. To monitor the whole repository, use the `refs/heads/*` rule.
diff --git a/topics/how-to.md b/topics/how-to.md
index 2f7b53f47..9d3c4d99c 100644
--- a/topics/how-to.md
+++ b/topics/how-to.md
@@ -464,7 +464,7 @@ If you are creating a copy (as opposed to moving the server this way), it is imp
If you are creating a __test server__, you need to ensure that the users and production systems are not affected. Typically, this means you need to:
* disable the email (in the "Administration > Notifier" sections) and possibly also custom notifiers or change their settings to prevent the new server from sending out notifications;
* disable email verification (in the "Administration > Authentication" section);
-* be sure not to run any builds which change (for example, deploy to) production environments. This also typically includes Maven builds deploying to non-local repositories. You can prevent any builds from starting by pausing the [build queue](build-queue.md);
+* be sure not to run any builds which change (for example, deploy to) production environments. This also typically includes Maven builds deploying to non-local repositories. You can prevent any builds from starting by pausing the [build queue](working-with-build-queue.md);
* disable cloud integration (so that it does not interfere with the main server);
* disable external artifact storage (as otherwise running/deleting builds and server clean-up will affect the storage which might be used by the production server);
* disable Docker registry clean-up (or just disable clean-up on the server);
@@ -570,7 +570,7 @@ Do the following:
%dep..system.build.number%
```
-Where `` is the [ID of the build configuration](build-configuration.md) C. The approach works best when builds reuse is turned off via the [Snapshot Dependencies](snapshot-dependencies.md) snapshot dependency option set to off.
+Where `` is the [ID of the build configuration](managing-builds.md) C. The approach works best when builds reuse is turned off via the [Snapshot Dependencies](snapshot-dependencies.md) snapshot dependency option set to off.
[Read more](predefined-build-parameters.md#Predefined+Configuration+Parameters) about dependency properties.
@@ -757,7 +757,7 @@ In case a build fails on some agent, it is possible to debug it on this very age
1. Go to the __Agents__ page in the TeamCity web UI and [select the agent](viewing-build-agent-details.md).
2. [Disable the agent](build-agents-configuration-and-maintenance.md#Enabling%2FDisabling+Agents+via+UI) to temporarily remove it from the build grid. Add a comment (optional). To enable the agent automatically after a certain time period, check the corresponding box and specify the time.
3. [Select the build](working-with-build-results.md) to debug.
-4. Open the [Custom Run](running-custom-build.md#Run+Custom+Build+dialog) dialog and specify the following options:
+4. Open the [Custom Run](running-custom-build.md) dialog and specify the following options:
a. In the __Agent__ drop-down menu, select the disabled agent.
b. It is recommended to select the __run as [Personal Build](personal-build.md)__ option to avoid intersection with regular builds.
5. When debugging is complete, enable the agent manually if automatic reenabling has not been configured.
@@ -769,7 +769,7 @@ You can also perform [remote debugging](remote-debug.md) of tests on an agent vi
If a build containing several steps fails at a certain step, it is possible to debug the step that breaks. Do the following:
1. Go to the build configuration and disable the build steps up to the one you want to debug.
2. [Select the build](working-with-build-results.md) to debug.
-3. Open the [Custom Run](running-custom-build.md#Run+Custom+Build+dialog) dialog and select the __put the build to the [queue top](build-queue.md)__ to give you build the priority.
+3. Open the [Custom Run](running-custom-build.md) dialog and select the __put the build to the [queue top](working-with-build-queue.md#Moving+Builds+to+Top)__ to give you build the priority.
4. When debugging is complete, reenable the build steps.
## Watch Several TeamCity Servers with Windows Tray Notifier
diff --git a/topics/identifier.md b/topics/identifier.md
index ad681019a..87692573b 100644
--- a/topics/identifier.md
+++ b/topics/identifier.md
@@ -1,7 +1,7 @@
[//]: # (title: Entity IDs)
[//]: # (auxiliary-id: Entity IDs;Identifier)
-An _ID_ is an identifier given to TeamCity entities ([projects](project.md), [build configurations](build-configuration.md), [templates](build-configuration-template.md), [VCS roots](vcs-root.md), and so on).
+An _ID_ is an identifier given to TeamCity entities ([projects](project.md), [build configurations](managing-builds.md), [templates](build-configuration-template.md), [VCS roots](vcs-root.md), and so on).
Each entity has two identifiers:
* [external ID](#External+IDs)
@@ -50,10 +50,10 @@ TeamCity projects, build configurations, and VCS roots have a UUID which is an a
Project
- Build Configuration
+ Build Configuration
- Managing Projects and Build Configurations
+ Creating and Editing Projects
Creating and Editing Build Configurations
Configuring VCS Roots
Accessing Server by HTTP
diff --git a/topics/integrating-teamcity-with-docker.md b/topics/integrating-teamcity-with-docker.md
index 3da06c4b8..66f398f5d 100644
--- a/topics/integrating-teamcity-with-docker.md
+++ b/topics/integrating-teamcity-with-docker.md
@@ -16,7 +16,7 @@ You can learn more details about the listed tools in the dedicated Help articles
The integration requires [Docker](https://docs.docker.com/engine/installation/) to be installed on the [build agents](build-agent.md). To use the [Docker Compose](docker-compose.md) build runner, you also need to install [Docker Compose](https://docs.docker.com/compose/install/).
TeamCity periodically checks if Docker is available on active build agents. Based on the `docker.server.version` and `docker.version` variables received from the agents, TeamCity distributes builds that use Docker only between agents with the installed Docker engine.
-If a [build configuration](build-configuration.md) uses the [Docker runner](docker.md) or the [Docker Wrapper extension](docker-wrapper.md), TeamCity automatically adds the `docker.server.version` [agent compatibility requirement](configuring-agent-requirements.md) for this configuration.
+If a [build configuration](managing-builds.md) uses the [Docker runner](docker.md) or the [Docker Wrapper extension](docker-wrapper.md), TeamCity automatically adds the `docker.server.version` [agent compatibility requirement](configuring-agent-requirements.md) for this configuration.
## Supported Environments
diff --git a/topics/integrating-teamcity-with-issue-tracker.md b/topics/integrating-teamcity-with-issue-tracker.md
index 672d66e3e..f95963780 100644
--- a/topics/integrating-teamcity-with-issue-tracker.md
+++ b/topics/integrating-teamcity-with-issue-tracker.md
@@ -11,11 +11,11 @@ Enabling integration for the project also enables it for all its subprojects; if
TeamCity supports [Jira](jira.md), [Bugzilla](bugzilla.md), [YouTrack](youtrack.md), [GitHub](github.md), [Bitbucket Cloud](bitbucket-cloud.md), and Azure DevOps Server (formerly [TFS](azure-board-work-items.md)) trackers out of the box. The [Supported Platforms and Environments](supported-platforms-and-environments.md#Issue+Trackers) page lists supported versions.
-When an integration is configured, TeamCity automatically transforms an issue ID (=issue key in Jira, work item ID in Azure DevOps Server) mentioned in the VCS commit comment into a link to the corresponding issue, and the basic issue details are displayed in the TeamCity web UI when hovering over the icon next to the issue ID (for example, on the __[Changes](working-with-build-results.md#Changes)__ tab of the build results).
+When an integration is configured, TeamCity automatically transforms an issue ID (=issue key in Jira, work item ID in Azure DevOps Server) mentioned in the VCS commit comment into a link to the corresponding issue, and the basic issue details are displayed in the TeamCity web UI when hovering over the icon next to the issue ID (for example, on the __[Changes](build-results-page.md#Changes+Tab)__ tab of Build Results).
-Issues fixed in the build can also be viewed on the __[Issues](working-with-build-results.md#Related+Issues)__ tab of the build results. You can filter the list to a particular range of builds and view issues mentioned in comments with their states.
+Issues fixed in the build can also be viewed on the __[Issues](build-results-page.md#Issues+Tab)__ tab of the build results. You can filter the list to a particular range of builds and view issues mentioned in comments with their states.
@@ -125,7 +125,7 @@ For example, if a project ID is `TW`, an issue ID like `TW-18802` mentioned in a
For __Bugzilla__, __GitHub__, and __Bitbucket Cloud__, you need to specify the __Issue ID Pattern__: a [Java Regular Expression](http://java.sun.com/j2se/1.5.0/docs/api/java/util/regex/Pattern.html) pattern to find the issue ID in the text. The matched text (or the first group if there are groups defined) is used as the issue number. The most common case is `#(\d+)` — this will extract `1234` as the issue ID from the text `Fix for #1234`.
-TeamCity will resolve the issue number mentioned in a VCS comment and will display a link to this issue in the UI (for example, on the __[Changes](working-with-build-results.md#Changes)__ page, or the __[Issues](working-with-build-results.md#Related+Issues)__ tab of __[Build Results](working-with-build-results.md)__).
+TeamCity will resolve the issue number mentioned in a VCS comment and will display a link to this issue in the UI (for example, on the __[Changes](build-results-page.md#Changes+Tab)__ page, or the __[Issues](build-results-page.md#Issues+Tab)__ tab of __[Build Results](working-with-build-results.md)__).
## Integrating TeamCity with Other Issue Trackers
{product="tc"}
diff --git a/topics/integrating-teamcity-with-other-tools.md b/topics/integrating-teamcity-with-other-tools.md
index 82d27b98a..16adee8be 100644
--- a/topics/integrating-teamcity-with-other-tools.md
+++ b/topics/integrating-teamcity-with-other-tools.md
@@ -1,13 +1,951 @@
[//]: # (title: Integrating TeamCity with Other Tools)
[//]: # (auxiliary-id: Integrating TeamCity with Other Tools)
-In this section:
+One of the key features of TeamCity is straightforward integration with modern software technologies and platforms. To ensure our users are able to integrate every component of their CI/CD pipeline with TeamCity, we either:
+* provide smart detection and handy UI controls on the TeamCity side, or
+* expose specialized [REST API](https://www.jetbrains.com/help/teamcity/rest/teamcity-rest-api-documentation.html) endpoints for easier scripting and integration on a third-party system's side.
-* [Integrating TeamCity with VCS Hosting Services](integrating-teamcity-with-vcs-hosting-services.md)
-* [Integrating TeamCity with Issue Tracker](integrating-teamcity-with-issue-tracker.md)
-* [Mapping External Links in Comments](mapping-external-links-in-comments.md)
+There are many places in the TeamCity UI where you can set up or adjust software integrations, depending on their context. This article gives an overview of third-party software and platforms supported in TeamCity out of the box. Remember that you can extend this scope by [installing additional plugins](installing-additional-plugins.md) or even [writing your own ones](https://plugins.jetbrains.com/docs/teamcity/developing-teamcity-plugins.html).
+See also [versions of platforms and environments](supported-platforms-and-environments.md) currently supported in TeamCity.
{product="tc"}
-* [External Changes Viewer](external-changes-viewer.md)
+
+There are many places in the TeamCity UI where you can set up or adjust software integrations, depending on their context. This article gives an overview of third-party software and platforms supported in TeamCity out of the box.
+See also [versions of platforms and environments](supported-platforms-and-environments.md) currently supported in TeamCity.
+{product="tcc"}
+
+The tables below are updated in accordance with the newly introduced integrations and whenever we have extra guides to share.
+
+## Operating Systems and Databases
{product="tc"}
+
+
+| Software | Available Integrations |
+
+|
+
+**Windows**
+
+ |
+
+* [Installing TeamCity Server on a Windows machine](install-teamcity-server-on-windows.md)
+* [Installing TeamCity Agent on a Windows machine](install-teamcity-agent.md#Install+from+Windows+Executable+File) and running builds on Windows
+
+ |
+
+|
+
+**Linux**
+
+ |
+
+* [Installing TeamCity Server on a Linux machine](install-teamcity-server-on-linux-or-macos.md)
+* [Installing TeamCity Agent on a Linux machine](install-teamcity-agent.md) and running builds on Linux
+
+ |
+
+|
+
+**macOS**
+
+ |
+
+* [Installing TeamCity Server on a macOS machine](install-teamcity-server-on-linux-or-macos.md)
+* [Installing TeamCity Agent on a macOS machine](install-teamcity-agent.md) and running builds on macOS
+
+ |
+
+|
+
+**MySQL**
+
+ |
+
+* [Storing build history, users, results, and some runtime data](set-up-external-database.md#MySQL)
+
+ | |
+
+|
+
+**Microsoft SQL Server**
+
+ |
+
+* [Storing build history, users, results, and some runtime data](set-up-external-database.md#Microsoft+SQL+Server)
+
+ | |
+
+|
+
+**PostgreSQL**
+
+ |
+
+* [Storing build history, users, results, and some runtime data](set-up-external-database.md#PostgreSQL)
+
+ | |
+
+|
+
+**Oracle**
+
+ |
+
+* [Storing build history, users, results, and some runtime data](set-up-external-database.md#Oracle)
+
+ | |
+
+
+
+## Software Development Platforms and Build Tools
+
+
+| Software | Available Integrations | Extra Guides and Tutorials |
+
+|
+
+**Java**, including
+* **Maven**
+* **Gradle**
+* **Ant**
+
+ |
+
+* Automating build tasks with:
+ * [Apache Maven](maven.md), using [special build triggers for Maven](configuring-maven-triggers.md)
+ * [Gradle](gradle.md)
+ * [Ant](ant.md)
+* [Autodiscovery of Maven, Gradle, and Ant build steps in a source project](configuring-build-steps.md#Autodetecting+Build+Steps)
+* Autodetection of [Maven](maven.md#Maven+runner+settings) and Gradle installations on a build agent
+* [Running a Maven, Gradle, or Ant build step inside a Docker container](docker-wrapper.md)
+* [Reporting Java code inspection results for a build](inspections.md)
+* [Detecting Java code duplicates in a build's source](duplicates-finder-java.md)
+* [Detailed test reports for JUnit and TestNG frameworks on the fly](java-testing-frameworks-support.md)
+* [Detailed code coverage](configuring-java-code-coverage.md)
+
+ |
+
+* [Building and Testing Java with Maven in TeamCity (2021)](https://www.jetbrains.com/teamcity/tutorials/maven-build-configure-test/)
+* [Incremental Building with Maven and TeamCity (2012)](https://blog.jetbrains.com/teamcity/2012/03/incremental-building-with-maven-and-teamcity/)
+* [Building and Testing Java with Gradle in TeamCity (2021)](https://www.jetbrains.com/teamcity/tutorials/gradle-build-configure-test/)
+* [Configuring Artifact Dependencies Using Ant Build Script](artifact-dependencies.md#Configuring+Artifact+Dependencies+Using+Ant+Build+Script)
+* [Get TeamCity Artifacts Using HTTP, Ant, Gradle and Maven (2012)](https://blog.jetbrains.com/teamcity/2012/06/teamcity-ivy-gradle-maven/)
+
+ |
+
+|
+
+**.NET**, including
+* **MSBuild**
+* **NAnt**
+* **Visual Studio Solutions**
+* **FxCop**
+* **C# Script**
+* **C#**
+* **VB.NET**
+* **NuGet**
+
+ |
+
+* [Autodiscovery of .NET build steps in a source project](configuring-build-steps.md#Autodetecting+Build+Steps)
+* [Autodetection of a .NET installation on a build agent](net.md#.NET+Version+Detection+Algorithm)
+* Cross-platform .NET builds
+* [Running .NET CLI commands](net.md#Build+Runner+Options)
+* [Running MSBuild commands](net.md#msbuild)
+* [Running devenv](net.md#devenv-build-action)
+* [Running any custom .NET commands](net.md#Custom+Commands)
+* [Running a .NET build step inside a Docker container](docker-wrapper.md)
+* [Detailed and structured test reports for .NET frameworks on the fly](net-testing-frameworks-support.md)
+* [Detailed code coverage](configuring-.net-code-coverage.md)
+* [Reporting .NET code inspection results for a build](inspections-resharper.md)
+* [Detecting .NET code duplicates in a build's source](duplicates-finder-resharper.md)
+* [Uploading to and downloading packages from NuGet feeds](nuget.md):
+ * Support for public, private NuGet feeds, and an ability to [use TeamCity as a private NuGet feed](using-teamcity-as-nuget-feed.md)
+ {product="tc"}
+ * Automatically [installing](nuget-installer.md), [packing](nuget-pack.md), and [publishing packages](nuget-publish.md)
+ * [Triggering builds on updates in a NuGet feed](nuget-dependency-trigger.md)
+* [Using FxCop for inspecting .NET assemblies](fxcop.md)
+* [Using NAnt to run build scripts](nant.md)
+* [Using C# Scripting to run build scripts](c-script.md)
+
+ |
+
+* [Building .NET Projects Using TeamCity (2021)](https://www.jetbrains.com/teamcity/tutorials/dotnet-build-configure-test/)
+* [TeamCity integration with .NET, Part 1: New approach and demo (2020)](https://blog.jetbrains.com/teamcity/2020/12/teamcity-integration-with-net-part-1-new-approach-and-demo/)
+* [TeamCity integration with .NET, Part 2: Testing and building projects (2020)](https://blog.jetbrains.com/teamcity/2020/12/teamcity-integration-with-net-part-2-testing-and-building-projects/)
+* [TeamCity integration with .NET, Part 3: Deploying projects (2020)](https://blog.jetbrains.com/teamcity/2020/12/teamcity-integration-with-net-part-3-deploying-projects/)
+* [How to automate CI/CD tasks with C# Scripting in TeamCity (2021)](https://blog.jetbrains.com/teamcity/2021/11/how-to-automate-ci-cd-tasks-with-c-scripting-in-teamcity/)
+
+ |
+
+|
+
+**Command Line**
+
+ |
+
+* Performing any command-line actions across platforms with the simple [Command Line](command-line.md) runner
+
+ |
+
+* [Video tutorial: How to run command line scripts (2022)](https://www.youtube.com/watch?v=oKNdLRrO3mA)
+
+ |
+
+|
+
+**PowerShell**
+
+ |
+
+* [Autodetection of a PowerShell installation on a build agent](net.md#.NET+Version+Detection+Algorithm)
+* [Running PowerShell scripts across platforms](powershell.md) for various build tasks
+* [Running a PowerShell build step inside a Docker container](docker-wrapper.md)
+
+ |
+
+ |
+
+|
+
+**Python**
+
+ |
+
+* [Autodiscovery of Python build steps in a source project](configuring-build-steps.md#Autodetecting+Build+Steps)
+* [Autodetection of a Python installation on a build agent](python.md#pythonVersion)
+* [Cross-platform execution of Python scripts](python.md)
+* Support for Pipenv, Poetry, Venv, and Virtualenv
+* A structured build log output based on build stages and test reports
+* [Running a Python build step inside a Docker container](docker-wrapper.md)
+
+ |
+
+* [Building and Testing Python Code with TeamCity (2021)](https://www.jetbrains.com/teamcity/tutorials/python-build-configure-test/)
+* [Video tutorial: New in TeamCity 2020.2: Python Build Runner](https://www.youtube.com/watch?v=DOLY1K5e8hQ)
+
+ |
+
+|
+
+**Kotlin**
+
+ |
+
+* [Cross-platform execution of build scripts written in Kotlin](kotlin-script.md)
+* [Using Kotlin DSL for configuring TeamCity project and build settings as code](kotlin-dsl.md)
+
+ |
+
+* [Kotlin DSL for Beginners: Recommended Refactorings (2021)](https://blog.jetbrains.com/teamcity/2021/04/kotlin-dsl-for-beginners-recommended-refactorings/)
+* [Creating TeamCity project templates with Kotlin DSL context parameters (2020)](https://blog.jetbrains.com/teamcity/2020/09/creating-teamcity-project-templates-with-kotlin-dsl-context-parameters/)
+* [Configuration as Code, Part 1: Getting Started with Kotlin DSL (2019)](https://blog.jetbrains.com/teamcity/2019/03/configuration-as-code-part-1-getting-started-with-kotlin-dsl/)
+* [Configuration as Code, Part 2: Working with Kotlin Scripts (2019)](https://blog.jetbrains.com/teamcity/2019/03/configuration-as-code-part-2-working-with-kotlin-scripts/)
+* [Configuration as Code, Part 3: Creating Build Configurations Dynamically (2019)](https://blog.jetbrains.com/teamcity/2019/04/configuration-as-code-part-3-creating-build-configurations-dynamically/)
+* [Configuration as Code, Part 4: Extending the TeamCity DSL (2019)](https://blog.jetbrains.com/teamcity/2019/04/configuration-as-code-part-4-extending-the-teamcity-dsl/)
+* [Configuration as Code, Part 5: Using DSL extensions as a library (2019)](https://blog.jetbrains.com/teamcity/2019/04/configuration-as-code-part-5-using-dsl-extensions-as-a-library/)
+* [Configuration as Code, Part 6: Testing Configuration Scripts (2019)](https://blog.jetbrains.com/teamcity/2019/05/configuration-as-code-part-6-testing-configuration-scripts/)
+
+ |
+
+|
+
+**Node.js**
+
+ |
+
+* [Autodiscovery of JavaScript build steps in a source project](nodejs.md#Autodetecting+JavaScript+Steps)
+* [Running npm, yarn, and node commands within a build](nodejs.md)
+* A structured build log output based on build stages and test reports
+* [Running a Node.js script inside a Docker container](docker-wrapper.md)
+* Support for ESlint, Jest, and Mocha
+* [Accessing private NPM registries](nodejs.md#Accessing+Private+NPM+Registries)
+
+ |
+
+* [Video tutorial: New in TeamCity 2021.1: Node.js Runner](https://www.youtube.com/watch?v=8-m5GFrxUzw)
+
+ |
+
+|
+
+**Ruby**
+
+ |
+
+* [Automating build tasks by running a Rakefile within a build](rake.md)
+* Support for Test::Unit, Test-Spec, Shoulda, RSpec, and Cucumber
+
+ |
+
+ |
+
+|
+
+**SBT (Scala)**
+
+ |
+
+* [Building and testing sources with Simple Build Tool's (Scala)](simple-build-tool-scala.md)
+
+ |
+
+ |
+
+|
+
+**Xcode**
+
+ |
+
+* [Running an Xcode scheme within a build](xcode-project.md)
+* A structured build log output based on Xcode build stages, compilation errors, and test reports
+* Automatically added [agent requirements](agent-requirements.md) to a specific version of Xcode or IDE
+
+ |
+ |
+
+
+
+## Testing Frameworks and Code Coverage
+
+
+| Software | Available Integrations |
+
+|
+
+**JUnit**
+
+ |
+
+* Detailed on-the-fly test reporting for [supported Java testing frameworks](java-testing-frameworks-support.md)
+* [Running risk-group tests first](running-risk-group-tests-first.md)
+
+ |
+
+|
+
+**TestNG**
+
+ |
+
+* Detailed on-the-fly test reporting for [supported Java testing frameworks](java-testing-frameworks-support.md)
+* [Running risk-group tests first](running-risk-group-tests-first.md)
+
+ |
+
+|
+
+**NUnit**
+
+ |
+
+* [Running NUnit tests](nunit.md) and showing detailed test results in the build overview
+* [Running risk-group tests first](running-risk-group-tests-first.md)
+
+ |
+
+|
+
+**MSTest / VSTest**
+
+ |
+
+* [Testing a project and automatically importing detailed test results](net.md#vstest)
+
+ |
+
+|
+
+**MSpec**
+
+ |
+
+* [Running MSpec tests and code coverage](mspec.md) and showing detailed test results in the build overview
+
+ |
+
+|
+
+**Test::Unit, Test-Spec, Shoulda, RSpec, and Cucumber**
+
+ |
+
+* [Running tests](rake.md) and showing detailed test results in the build overview
+
+ |
+
+|
+
+**Pytest**
+
+ |
+
+* [Running tests](python.md) and showing detailed test results in the build overview
+
+ |
+
+|
+
+**Python Unittest**
+
+ |
+
+* [Running tests](python.md) and showing detailed test results in the build overview
+
+ |
+
+|
+
+**JaCoCo**
+
+ |
+
+* [Measuring coverage metrics and code complexity of a Java build's sources](jacoco.md)
+* [Importing JaCoCo coverage](jacoco.md#Importing+JaCoCo+coverage+data+to+TeamCity)
+
+ |
+
+|
+
+**Emma**
+
+ |
+
+* [Measuring coverage metrics and code complexity of a Java build's sources](emma.md)
+
+ |
+
+|
+
+**IntelliJ IDEA coverage**
+
+ |
+
+* [Measuring coverage metrics and code complexity of a Java build's sources](intellij-idea.md)
+
+ |
+
+|
+
+**JetBrains dotCover**
+
+ |
+
+* [Measuring coverage metrics and code complexity of a .NET build's sources](jetbrains-dotcover.md)
+
+ |
+
+|
+
+**NCover**
+
+ |
+
+* [Measuring coverage metrics and code complexity of a .NET build's sources](ncover.md)
+
+ |
+
+|
+
+**PartCover**
+
+ |
+
+* [Measuring coverage metrics and code complexity of a .NET build's sources](partcover.md)
+
+ |
+
+|
+
+**Flake8**
+
+ |
+
+* [Parsing Python files and showing coverage reports in build results](partcover.md)
+
+ |
+
+|
+
+**Pylint**
+
+ |
+
+* [Parsing Python files and showing coverage reports in build results](partcover.md)
+
+ |
+
+
+
+
+## Version Control Systems
+
+
+| Software | Available Integrations | Extra Guides and Tutorials |
+
+|
+
+**Git**
+
+ |
+
+* [Building projects based on Git repositories](git.md)
+* [Remote run](remote-run.md), [remote debug](remote-debug.md), and [pretesting commits](pre-tested-delayed-commit.md) of Git-based projects
+* Multiple checkout modes on [server](git.md#Server+Settings) and [agent](git.md#GitAgentSettings) machines
+* [Support for Git LFS](git.md#Git+LFS)
+* [Automatically tagging build sources](vcs-labeling.md)
+* [Automatically merging build sources after successful builds](automatic-merge.md)
+
+
+ | |
+
+|
+
+**Subversion**
+
+ |
+
+* [Building projects based on SVN repositories](subversion.md)
+* [Remote run](remote-run.md), [remote debug](remote-debug.md), and [pretesting commits](pre-tested-delayed-commit.md) of SVN-based projects
+* [Automatically tagging build sources](vcs-labeling.md#Subversion+Labeling+Rules)
+
+ | |
+
+|
+
+**Perforce**
+
+ |
+
+* [Building projects based on Perforce Helix Core repositories](perforce.md)
+* [Using Perforce streams as feature branches](integrating-teamcity-with-perforce.md#Running+Builds+on+Perforce+Streams) and building their sources independently of each other
+* [Pre-testing and pre-building files in shelved changelists](integrating-teamcity-with-perforce.md#Running+Builds+on+Perforce+Shelved+Files)
+* [Reporting build statuses to code reviews in Perforce Helix Swarm](integrating-teamcity-with-perforce.md#Publishing+Build+Statuses+to+Perforce+Helix+Swarm)
+* [Automatic labeling of sources](vcs-labeling.md#Labeling+in+Perforce)
+* [Using post-commit hooks to avoid background polling](configuring-vcs-post-commit-hooks-for-teamcity.md#Using+post-commit+script+for+Perforce)
+
+ |
+
+* [Integrating TeamCity with Perforce (2022)](integrating-teamcity-with-perforce.md)
+
+ |
+
+|
+
+**Azure DevOps (TFVC)**
+
+ |
+
+* [Building projects based on TFVC repositories](perforce.md) across platforms
+* [Automatic labeling of sources](vcs-labeling.md)
+* [Remote run](remote-run.md), [remote debug](remote-debug.md), and [pretesting commits](pre-tested-delayed-commit.md) of TFVC-based projects
+
+ | |
+
+|
+
+**CVS**
+
+ |
+
+* [Building projects based on CVS repositories](cvs.md) across platforms
+* [Automatic labeling of sources](vcs-labeling.md)
+* [Remote run](remote-run.md), [remote debug](remote-debug.md), and [pretesting commits](pre-tested-delayed-commit.md) of CVS-based projects
+
+ | |
+
+|
+
+**Mercurial**
+
+ |
+
+* [Building projects based on Mercurial repositories](mercurial.md) across platforms
+* [Automatic labeling of sources](vcs-labeling.md)
+
+ | |
+
+|
+
+**Borland StarTeam**
+
+ |
+
+* [Building projects based on StarTeam repositories](starteam.md) across platforms
+* [Automatic labeling of sources](vcs-labeling.md)
+
+ | |
+
+
+
+## Data Transfer Protocols
+
+
+| Software | Available Integrations | Extra Guides and Tutorials |
+|
+
+**SSH**
+
+ |
+
+* [Storing SSH keys in TeamCity and reusing them in builds](git.md) by means of an [SSH agent](ssh-agent.md)
+* [Executing arbitrary remote commands using SSH](ssh-exec.md)
+* [Uploading files/directories via SSH (using SCP or SFTP protocols)](ssh-upload.md)
+
+ |
+
+* [Video tutorial: How to checkout SSH repositories (2022)](https://www.youtube.com/watch?v=nUTb1BjMMoE)
+* [Video tutorial: How to use SSH during your builds (2022)](https://www.youtube.com/watch?v=D6JOyGd4pWI)
+
+ |
+
+
+
+|
+
+**Amazon S3 protocols**
+
+ |
+
+* [Uploading build artifacts to an Amazon S3 storage](configuring-artifacts-storage.md#Amazon+S3+Support)
+
+ | |
+
+|
+
+**SMB**
+
+ |
+
+* [Uploading files to Windows shares during builds via SMB](smb-upload.md)
+
+ | |
+
+|
+
+**FTP**
+
+ |
+
+* [Uploading files to an FTP server during builds](ftp-upload.md)
+
+ | |
+
+
+
+## VCS Hosting Services
+
+
+| Software | Available Integrations | Extra Guides and Tutorials |
+
+|
+
+**GitHub.com / GitHub Enterprise**
+
+ |
+
+* [Creating a project or build configuration from a GitHub repository URL](creating-and-editing-projects.md#Creating+project+pointing+to+repository+URL)
+* [Guessing VCS root settings from a GitHub repository URL](guess-settings-from-repository-url.md)
+* [Creating a Git VCS root from a GitHub repository URL](git.md)
+* [Inserting links to GitHub issues when detecting their IDs in commit messages](github.md)
+* [Building sources of GitHub pull requests](pull-requests.md#GitHub+Pull+Requests)
+* [Authenticating with a GitHub account in TeamCity](configuring-authentication-settings.md#GitHub.com)
+
+ |
+
+* [Video tutorial: How to integrate TeamCity and GitHub (2022)](https://www.youtube.com/watch?v=hbh7sk5sGTc)
+* [Video tutorial: How to use GitHub commit hooks for faster checkouts (2022)](https://www.youtube.com/watch?v=VzDI2HoiHk4)
+* [Video tutorial: How to send build information to GitHub, Jira etc. (2022)](https://www.youtube.com/watch?v=o0oj7mOcNvc)
+* [Video tutorial: How to work with pull requests (2022)](https://youtu.be/4yFck9PvXI4)
+* [Building GitHub pull requests with TeamCity (2019)](https://blog.jetbrains.com/teamcity/2019/08/building-github-pull-requests-with-teamcity/)
+
+ |
+
+|
+
+**GitLab.com / GitLab CE/EE**
+
+ |
+
+* [Creating a project or build configuration from a GitLab repository URL](creating-and-editing-projects.md#Creating+project+pointing+to+repository+URL)
+* [Guessing VCS root settings from a GitHub repository URL](guess-settings-from-repository-url.md)
+* [Building sources of GitLab merge requests](pull-requests.md#GitLab+Merge+Requests)
+* [Authenticating with a GitLab account in TeamCity](configuring-authentication-settings.md#GitLab.com)
+
+ |
+
+* [Video tutorial: New in TeamCity 2019.1 — GitLab integration and merge requests support](https://www.youtube.com/watch?v=aE150gCfQyI)
+* [Video tutorial: How to work with pull requests (2022)](https://youtu.be/4yFck9PvXI4)
+
+ |
+
+|
+
+**Bitbucket Cloud / Bitbucket Server**
+
+ |
+
+* [Creating a project or build configuration from a Bitbucket repository URL](creating-and-editing-projects.md#Creating+project+pointing+to+repository+URL)
+* [Guessing VCS root settings from a Bitbucket repository URL](guess-settings-from-repository-url.md)
+* [Creating a Mercurial VCS root from a Bitbucket repository URL](mercurial.md)
+* [Building sources of Bitbucket pull requests](pull-requests.md#Bitbucket+Cloud+Pull+Requests)
+* [Inserting links to Bitbucket Cloud issues when detecting their IDs in commit messages](bitbucket-cloud.md)
+* [Authenticating with a Bitbucket Cloud account in TeamCity](configuring-authentication-settings.md#Bitbucket+Cloud)
+
+ |
+
+* [Video tutorial: New in TeamCity 2020.2: Bitbucket Cloud Pull Request Support](https://youtu.be/M2wi6l0pZe4)
+* [Run and view TeamCity builds from Bitbucket](https://blog.jetbrains.com/teamcity/2021/05/run-and-view-teamcity-builds-from-bitbucket/)
+* [Video tutorial: How to work with pull requests (2022)](https://youtu.be/4yFck9PvXI4)
+
+ |
+
+|
+
+**Azure DevOps Services**
+
+ |
+
+* [Creating a project or build configuration from an Azure DevOps repository URL](creating-and-editing-projects.md#Creating+project+pointing+to+repository+URL)
+* [Guessing VCS root settings from an Azure DevOps repository URL](guess-settings-from-repository-url.md)
+* [Building sources of Azure DevOps pull requests](pull-requests.md#Azure+DevOps+Pull+Requests)
+* [Inserting links to Azure Board Work Items issues when detecting their IDs in commit messages](azure-board-work-items.md).
+* [Authenticating with an Azure DevOps Services account in TeamCity](configuring-authentication-settings.md#Azure+DevOps+Services)
+
+ |
+
+* [Video tutorial: How to work with pull requests (2022)](https://youtu.be/4yFck9PvXI4)
+
+ |
+
+|
+
+**JetBrains Space**
+
+ |
+
+* [Creating a project or build configuration from a JetBrains Space repository URL](creating-and-editing-projects.md#Creating+project+pointing+to+repository+URL).
+* [Guessing VCS root settings from a JetBrains Space repository URL](guess-settings-from-repository-url.md).
+* [Authenticating with a JetBrains Space account in TeamCity](configuring-authentication-settings.md#JetBrains+Space).
+
+ |
+
+* [How to configure CI/CD for JetBrains Space](how-to-configure-cicd-for-jetbrains-space.md)
+
+ |
+
+## Virtualization Solutions
+
+
+| Software | Available Integrations | Extra Guides and Tutorials |
+
+|
+
+**Docker**
+
+ |
+
+* [Launching Docker commands and creating a Docker image during a build](docker.md)
+* [Running some build steps inside a Docker container, across platforms](docker-wrapper.md)
+* [Automatically signing in to Docker registry before each build](docker-support.md)
+* [Displaying Docker-related information in build results](docker-support.md)
+* [Running multiple containers in a build with Docker Compose](docker-compose.md)
+* [Cleaning obsolete Docker images on build agents](integrating-teamcity-with-docker.md#Docker+Disk+Space+Cleaner)
+
+ |
+
* [Integrating TeamCity with Docker](integrating-teamcity-with-docker.md)
+ |
+
+
+
+
+
+## Cloud Hosting and Orchestration Solutions
+{product="tc"}
+
+
+| Software | Available Integrations |
+
+|
+
+**Amazon EC2**
+
+ |
+
+* [Running builds on cloud agents](setting-up-teamcity-for-amazon-ec2.md)
+
+ |
+
+|
+
+**VMWare vSphere and vCenter**
+
+ |
+
+* [Running builds on cloud agents](setting-up-teamcity-for-vmware-vsphere-and-vcenter.md)
+
+ |
+
+|
+
+**Kubernetes**
+
+ |
+
+* [Running builds on cloud agents](setting-up-teamcity-for-kubernetes.md)
+
+ |
+|
+
+**Microsoft Azure**
+(via additional plugin)
+
+ |
+
+* [Running builds on cloud agents](https://plugins.jetbrains.com/plugin/9260-azure-resource-manager-cloud-support)
+
+Read [how to install a plugin in TeamCity](installing-additional-plugins.md).
+
+ |
+|
+
+**Google Cloud**
+(via additional plugin)
+
+ |
+
+* [Running builds on cloud agents](https://plugins.jetbrains.com/plugin/9704-google-cloud-agents)
+
+Read [how to install a plugin in TeamCity](installing-additional-plugins.md).
+
+ |
+
+
+## Issue Trackers
+
+
+| Software | Available Integrations | Extra Guides and Tutorials |
+
+|
+
+**JetBrains YouTrack**
+
+ |
+
+* [Providing links to related YouTrack issues from the TeamCity build overview](youtrack.md)
+
+ | |
+
+|
+
+**Atlassian Jira**
+
+ |
+
+* [Providing links to related Jira issues from the TeamCity build overview](jira.md)
+* [Reporting TeamCity build statuses to Jira Cloud](jira-cloud-integration.md)
+
+ |
+
+* [Video tutorial: How to integrate TeamCity and JIRA (Cloud) (2022)](https://www.youtube.com/watch?v=rK7faWbCh0Q)
+
+ |
+
+|
+
+**Bugzilla**
+
+ |
+
+* [Providing links to related Bugzilla issues from the TeamCity build overview](bugzilla.md)
+
+ | |
+
+__Integration with issue trackers is also represented in terms of integration with [VCS hosting services](#VCS+Hosting+Services)__.
+
+## IDEs
+
+
+| Software | Available Integrations | Extra Guides and Tutorials |
+
+|
+
+**IntelliJ Platform**
+
+ |
+
+* [Generating code coverage within a build](intellij-idea.md)
+* [Building a project created in IntelliJ IDEA](intellij-idea-project.md)
+* [Remote run](remote-run.md), [remote debug](remote-debug.md), and [pretesting commits](pre-tested-delayed-commit.md)
+* [Other numerous features](intellij-platform-plugin.md)
+
+ |
+
+* [TeamCity Integration with IntelliJ-based IDEs (2017)](https://blog.jetbrains.com/teamcity/2017/10/teamcity-integration-with-intellij-based-ides/)
+
+ |
+
+|
+
+**Microsoft Visual Studio**
+
+ |
+
+* [Running Visual Studio in command-line mode within a build](net.md#Visual+Studio+Command-Line+Mode)
+* [Remote run](remote-run.md) and [pretesting commits](pre-tested-delayed-commit.md)
+
+ |
+
+ |
+
+|
+
+**Eclipse**
+
+ |
+
+* [Remote run](remote-run.md) and [pretesting commits](pre-tested-delayed-commit.md)
+* [Other numerous features](eclipse-plugin.md)
+
+ | |
+
+## Notification Services
+
+
+| Software | Available Integrations | Extra Guides and Tutorials |
+
+|
+
+**Slack**
+
+ |
+
+* [Sending customizable notifications on different events in TeamCity to a Slack channel](notifications.md#Slack+Notifier)
+
+ |
+
+* [Video tutorial: How to integrate TeamCity and Slack (2022)](https://www.youtube.com/watch?v=d_Xuw7kkp4c)
+
+ |
+
+|
+
+**Web browsers**
+
+ |
+
+* [Showing customizable notifications on different TeamCity events in Google Chrome, Microsoft Edge, Opera, and Mozilla Firefox](browser-notifier.md)
+
+ |
+
+* [New TeamCity Notifier browser extension (2020)](https://blog.jetbrains.com/teamcity/2020/05/new-teamcity-notifier-browser-extension/)
+
+ |
+
+
+
+__TeamCity can also [send notifications via email](notifications.md#Email+Notifier).__
+
+
diff --git a/topics/integrating-teamcity-with-perforce.md b/topics/integrating-teamcity-with-perforce.md
index cbcd3de75..d23023998 100644
--- a/topics/integrating-teamcity-with-perforce.md
+++ b/topics/integrating-teamcity-with-perforce.md
@@ -177,7 +177,7 @@ TeamCity provides a dedicated hook script that should be saved on your Perforce
## Label Perforce Sources
-TeamCity can assign custom labels to Perforce project sources. The list of applied labels and their status is displayed on the __[Changes](working-with-build-results.md#Changes)__ tab of __Build Results__.
+TeamCity can assign custom labels to Perforce project sources. The list of applied labels and their status is displayed on the __[Changes](build-results-page.md#Changes+Tab)__ tab of __Build Results__.
To configure automatic labeling for a build configuration:
1. Go to __Build Configuration Settings | Build Features__.
diff --git a/topics/integrating-teamcity-with-vcs-hosting-services.md b/topics/integrating-teamcity-with-vcs-hosting-services.md
index 99938976d..08b2113c6 100644
--- a/topics/integrating-teamcity-with-vcs-hosting-services.md
+++ b/topics/integrating-teamcity-with-vcs-hosting-services.md
@@ -27,7 +27,7 @@ Integration with GitHub allows you to:
* create a [VCS root from URL](guess-settings-from-repository-url.md)
* create a [Git VCS root](git.md)
* integrate with a [GitHub issue tracker](github.md)
-* enable [GitHub.com authentication](configuring-authentication-settings.md#GitHub.com)
+* enable [GitHub authentication](configuring-authentication-settings.md#GitHub.com)
See how to configure a connection to GitHub.com or GitHub Enterprise [here](configuring-connections.md#GitHub).
@@ -39,7 +39,7 @@ title="TeamCity tutorial — How to integrate TeamCity and GitHub"/>
Integration with GitLab allows you to:
* create a [project from GitLab URL](creating-and-editing-projects.md#Creating+project+pointing+to+repository+URL)
* create a [VCS root from URL](guess-settings-from-repository-url.md)
-* enable [GitLab.com authentication](configuring-authentication-settings.md#GitLab.com)
+* enable [GitLab authentication](configuring-authentication-settings.md#GitLab.com)
See how to configure a connection to GitLab.com or GitLab CE/EE [here](configuring-connections.md#GitLab).
diff --git a/topics/intellij-idea.md b/topics/intellij-idea.md
index 4c42870b9..df70040a7 100644
--- a/topics/intellij-idea.md
+++ b/topics/intellij-idea.md
@@ -1,7 +1,7 @@
[//]: # (title: IntelliJ IDEA)
[//]: # (auxiliary-id: IntelliJ IDEA)
-The IntelliJ IDEA coverage engine in TeamCity is the same engine that is used within IntelliJ IDEA to measure code coverage. This coverage attaches to the JVM as a java agent and instruments classes on the fly when they are loaded by the JVM. In particular, it means that classes are not changed on the disk and can be safely used for distribution packages.
+The IntelliJ IDEA coverage engine in TeamCity is the same engine that is used within IntelliJ IDEA to measure code coverage. This coverage attaches to the JVM as a jJava agent and instruments classes on the fly when they are loaded by the JVM. In particular, it means that classes are not changed on the disk and can be safely used for distribution packages.
The IntelliJ IDEA coverage engine currently supports Class, Method, and Line coverage. There is no Branch/Block coverage yet.
diff --git a/topics/intellij-platform-plugin.md b/topics/intellij-platform-plugin.md
index d38afc89e..928e6ab02 100644
--- a/topics/intellij-platform-plugin.md
+++ b/topics/intellij-platform-plugin.md
@@ -23,7 +23,7 @@ TeamCity integration provides the following features:
* work with the results of server-side code duplicates search in the dedicated tool window
* accessing the server-side code coverage information and visualizing the portions of code covered by unit tests
* viewing build compilation errors in a separate tab of the build results pane with navigation to source code
-* rerununing failed tests from IntelliJ IDEA plugin using JUnit or TestNG
+* rerunning failed tests from IntelliJ IDEA plugin using JUnit or TestNG
* opening the patch from the change details web page (for this feature to work you need to have IDEA X installed)
## Installing TeamCity plugin
diff --git a/topics/introduction-to-teamcity-terminology.md b/topics/introduction-to-teamcity-terminology.md
index 71ddece26..111a9f287 100644
--- a/topics/introduction-to-teamcity-terminology.md
+++ b/topics/introduction-to-teamcity-terminology.md
@@ -7,7 +7,7 @@ The following guide explains the main TeamCity terms and concepts. For a quick r
## TeamCity Object Hierarchy
-_[Projects](project.md)_ are the topmost objects of the TeamCity hierarchy, and _Root project_ is the main default project that contains all your custom projects and their subprojects. Each project serves for storing logically related _[build configurations](build-configuration.md)_ and defining their common settings and parameters. Most often, a TeamCity project corresponds to a single software product or its specific version.
+_[Projects](project.md)_ are the topmost objects of the TeamCity hierarchy, and _Root project_ is the main default project that contains all your custom projects and their subprojects. Each project serves for storing logically related _[build configurations](managing-builds.md)_ and defining their common settings and parameters. Most often, a TeamCity project corresponds to a single software product or its specific version.
Projects can be configured manually or automatically, from a VCS repository. The settings of each repository used in a project are stored in a dedicated preset called _[VCS root](vcs-root.md)_. Besides VCS roots, a project contains other settings shared between its nested subprojects and build configurations: _[cloud profile connections](teamcity-integration-with-cloud-solutions.md)_, _[common parameters](levels-and-priority-of-build-parameters.md)_, _[clean-up rules](teamcity-data-clean-up.md)_, and [many others](creating-and-editing-projects.md).
{product="tc"}
@@ -40,11 +40,11 @@ Example of a build chain in TeamCity:
## TeamCity Build Environment
-The [TeamCity server](install-and-start-teamcity-server.md) stores all the objects' settings, manages the _[build queue](build-queue.md)_, monitors the state of running builds, and performs many other tasks. You can install as many additional _[secondary servers](multinode-setup.md)_ as you need to ensure high availability and scalability of your setup.
+The [TeamCity server](install-and-start-teamcity-server.md) stores all the objects' settings, manages the _[build queue](working-with-build-queue.md)_, monitors the state of running builds, and performs many other tasks. You can install as many additional _[secondary servers](multinode-setup.md)_ as you need to ensure high availability and scalability of your setup.
You can host the server on your own machine or get a [TeamCity Cloud](https://www.jetbrains.com/teamcity/cloud/) subscription so your server is automatically launched and maintained in the cloud.
{product="tc"}
-The TeamCity server stores all the objects' settings, manages the _[build queue](build-queue.md)_, monitors the state of running builds, and performs many other tasks.
+The TeamCity server stores all the objects' settings, manages the _[build queue](working-with-build-queue.md)_, monitors the state of running builds, and performs many other tasks.
{product="tcc"}
A different piece of software is used for actually running builds — a _[build agent](build-agent.md)_. By default, you get three build agents with your TeamCity server but you can get more if required. A build agent software can be installed on a different machine or alongside the server.
@@ -61,10 +61,10 @@ To learn more about TeamCity, explore this Help further:
* The current Concepts section lists the main TeamCity objects and terms. Use it as a reference to learn about unfamiliar notions.
* To properly install and configure your setup, refer to [Supported Platforms and Environments](supported-platforms-and-environments.md) and [Installation](install-and-start-teamcity-server.md).
{product="tc"}
-* If you are using TeamCity only for managing and viewing builds, make sure to read the [User's Guide](user-s-guide.md).
-* If you have a Project Administrator or Server Administrator access, use the [Admin's Guide](administrator-s-guide.md) section to learn how to configure projects or how to use the Administration panel and maintain the server. This section also contains information on [licensing](licensing-policy.md) and [configuration as code in TeamCity](kotlin-dsl.md).
+* If you are using TeamCity only for managing and viewing builds, make sure to read [this section](managing-builds.md).
+* If you have a Project Administrator or Server Administrator access, use the [TeamCity Configuration and Maintenance](teamcity-configuration-and-maintenance.md) section to learn how to configure projects or how to use the Administration panel and maintain the server. This section also contains information on [licensing](licensing-policy.md) and [configuration as code in TeamCity](kotlin-dsl.md).
{product="tc"}
-* If you have a Project Administrator or Server Administrator access, use the [Admin's Guide](administrator-s-guide.md) section to learn how to configure projects or how to use the Administration panel and maintain the server. This section also contains information on [configuration as code in TeamCity](kotlin-dsl.md).
+* If you have a Project Administrator or Server Administrator access, use the [TeamCity Configuration and Maintenance](teamcity-configuration-and-maintenance.md) section to learn how to configure projects or how to use the Administration panel and maintain the server. This section also contains information on [configuration as code in TeamCity](kotlin-dsl.md).
{product="tcc"}
* Available TeamCity add-ins are described [here](installing-tools.md).
* Under [Extending TeamCity](extending-teamcity.md), advanced users can learn how to [run build scripts for interacting with TeamCity](build-script-interaction-with-teamcity.md), how to [use TeamCity REST API](https://www.jetbrains.com/help/teamcity/rest/teamcity-rest-api-documentation.html), and more.
diff --git a/topics/investigating-and-muting-build-failures.md b/topics/investigating-and-muting-build-failures.md
index aadf1992b..be043d68e 100644
--- a/topics/investigating-and-muting-build-failures.md
+++ b/topics/investigating-and-muting-build-failures.md
@@ -17,7 +17,7 @@ These permissions are granted to Project Administrators and System Administrator
## Assigning Investigations of Failed Build Configurations
To assign an investigation of a failed build configuration:
-1. Navigate to the __Overview__ tab of the __[Build Configuration Home](viewing-build-configuration-details.md)__ page (or the __Overview__ tab of the __[Build Results](working-with-build-results.md)__ page) and click __Assign investigation__. 
+1. Navigate to the __Overview__ tab of the __[Build Configuration Home](build-configuration-home-page.md)__ page (or the __Overview__ tab of the __[Build Results](working-with-build-results.md)__ page) and click __Assign investigation__.
2. Select a TeamCity user from the __Investigated by__ drop-down menu. 
3. Select the condition to resolve the investigation:
* _When build configuration is successful_
@@ -32,7 +32,7 @@ To assign similar investigations for other failed build configurations in the sa
## Assigning Investigations of Build Problems and Failed Tests
To assign an investigation of a particular build problem:
-1. Navigate to the __Overview__ tab of the [Build Results](working-with-build-results.md) page (or the __[Current Problems](viewing-tests-and-configuration-problems.md#Using+Current+Problems+Tab)__ tab of the __Project Home__), click the arrow next to the build problem, and then click __Investigate/Mute__.
+1. Navigate to the __Overview__ tab of the **[Build Results](working-with-build-results.md)** page (or the __[Current Problems](viewing-tests-and-configuration-problems.md#Using+Current+Problems+Tab)__ tab of the __Project Home__), click the arrow next to the build problem, and then click __Investigate/Mute__.
The _Investigate/Mute_ dialog opens.
2. Select a TeamCity user from the __Investigated by__ drop-down menu.
@@ -43,7 +43,7 @@ To assign an investigation of a particular build problem:
The user to whom the investigation is assigned can later [mark the problem as fixed](#Marking+Problems+as+Fixed) in this window.
4. Save the investigation.
-You can similarly assign an investigation of a failed test on the __Overview__ or __[Tests](working-with-build-results.md#Tests)__ tab of the __Build Results__.
+You can similarly assign an investigation of a failed test on the __Overview__ or __[Tests](build-results-page.md#Tests+Tab)__ tab of the __Build Results__.
## Muting Build Problems
@@ -61,7 +61,7 @@ To mute a particular build problem:
## Muting Tests
-You can mute a failed test or several tests at once on the __Overview__ or __[Tests](working-with-build-results.md#Tests)__ tab of the __Build Results__, similarly to [muting build problems](#Muting+Build+Problems).
+You can mute a failed test or several tests at once on the __Overview__ or __[Tests](build-results-page.md#Tests+Tab)__ tab of the __Build Results__, similarly to [muting build problems](#Muting+Build+Problems).
@@ -120,7 +120,7 @@ If the "_Automatically when fixed_" option is select in [Investigation](#Assigni
- Build Configuration Status
+ Build Configuration Status
Viewing Tests and Configuration Problems
diff --git a/topics/jenkins-to-teamcity-migration-guidelines.md b/topics/jenkins-to-teamcity-migration-guidelines.md
index e0005d040..65f323e67 100644
--- a/topics/jenkins-to-teamcity-migration-guidelines.md
+++ b/topics/jenkins-to-teamcity-migration-guidelines.md
@@ -88,7 +88,7 @@ Job/Item/Project
-[Build configuration](build-configuration.md)
+[Build configuration](managing-builds.md)
|
@@ -198,7 +198,7 @@ A Freestyle project is the most common project type in Jenkins so we describe th
There are some conceptual differences in how the build jobs are configured in Jenkins and TeamCity.
-[Build Configuration](build-configuration.md) is the TeamCitys counterpart of Jenkins Job/Item/Project. However, a Build Configuration requires a [Project](project.md) instance to be created first. In fact, the notion of Project in TeamCity is the first big difference that a user encounters when migrating from Jenkins. The Project contains a good portion of settings required for the build configurations. All settings that are assigned to a Project in TeamCity are listed [here](project.md).
+[Build Configuration](managing-builds.md) is the TeamCitys counterpart of Jenkins Job/Item/Project. However, a Build Configuration requires a [Project](project.md) instance to be created first. In fact, the notion of Project in TeamCity is the first big difference that a user encounters when migrating from Jenkins. The Project contains a good portion of settings required for the build configurations. All settings that are assigned to a Project in TeamCity are listed [here](project.md).
### VCS Roots
diff --git a/topics/jetbrains-dotcover.md b/topics/jetbrains-dotcover.md
index 8117635ab..f510dd27f 100644
--- a/topics/jetbrains-dotcover.md
+++ b/topics/jetbrains-dotcover.md
@@ -98,7 +98,7 @@ If you need to build binaries in one build and collect code coverage in another
* Build configuration __A__ compiles code with debugging information and creates an artifact with assemblies and `.pdb` files
* Build configuration __B__ runs tests with dotCover enabled and has a [snapshot dependency](build-dependencies-setup.md#Snapshot+Dependencies) on A.
-To display the source code in the [Code Coverage tab](working-with-build-results.md#Code+Coverage+Results) of build results of B, you need to point B to the same [VCS root](configuring-vcs-roots.md) as A to get your source code in an appropriate location (the [checkout root](build-checkout-directory.md)) and add an [artifact dependency](build-dependencies-setup.md#Artifact+Dependencies) on __build from the same chain__ of A (for dotCover to get the paths to the sources from the `.pdb` files).
+To display the source code in the __[Code Coverage](build-results-page.md#Code+Coverage+Tab)__ tab of build results of B, you need to point B to the same [VCS root](configuring-vcs-roots.md) as A to get your source code in an appropriate location (the [checkout root](build-checkout-directory.md)) and add an [artifact dependency](build-dependencies-setup.md#Artifact+Dependencies) on __build from the same chain__ of A (for dotCover to get the paths to the sources from the `.pdb` files).
You also need to tell TeamCity where to find the source code. To do this, perform the following:
1. Add the `teamcity.dotCover.sourceBase` configuration parameter with the value `%\teamcity.build.checkoutDir%` to the compiling build configuration A.
diff --git a/topics/jira.md b/topics/jira.md
index a3a548ec9..4ca39ac5f 100644
--- a/topics/jira.md
+++ b/topics/jira.md
@@ -11,11 +11,11 @@ This article describes how TeamCity behaves when integrated with Jira and contai
When integration with Jira is enabled, TeamCity automatically detects Jira [issue keys](https://support.atlassian.com/jira-software-cloud/docs/what-is-an-issue/#Workingwithissues-Issuekeys) mentioned in the comments of VCS commits. It transforms these keys into links to the corresponding issues in Jira and displays them to TeamCity users in the UI.
-To see the basic details of an issue in the TeamCity UI, open the __[Changes](working-with-build-results.md#Changes)__ tab of the related build’s results and hover over the icon next to the issue key:
+To see the basic details of an issue in the TeamCity UI, open the __[Changes](build-results-page.md#Changes+Tab)__ tab of the related build’s results and hover over the icon next to the issue key:
-Issues fixed in the build can be viewed on the __[Issues](working-with-build-results.md#Related+Issues)__ tab of the build results:
+Issues fixed in the build can be viewed on the __[Issues](build-results-page.md#Issues+Tab)__ tab of the build results:
diff --git a/topics/known-issues.md b/topics/known-issues.md
index b6c0cfa2a..a57fc94dc 100644
--- a/topics/known-issues.md
+++ b/topics/known-issues.md
@@ -469,6 +469,7 @@ __Cause__: NuGet caches the server responses, thus pulling does not detect the m
__Solution__: To send a new request directly to the server instead of the cache, use the `--no-cache` parameter in your request.
### Packages are not found in NuGet feed
+{product="tc"}
__Problem__: Not all packages are found in a NuGet feed, though artifacts are present on the disk and in the UI and teamcity-nuget.log does not indicate that indexing of packages is in progress.
diff --git a/topics/licensing-policy.md b/topics/licensing-policy.md
index ff031e93d..a8bcdc1ca 100644
--- a/topics/licensing-policy.md
+++ b/topics/licensing-policy.md
@@ -126,7 +126,7 @@ The same TeamCity distribution and installation are used for both editions. You
The current edition in use is noted in the footer of every TeamCity web UI page and on on the __Administration__ > __Licenses__ page as well as in `teamcity-server.log` on the server startup.
-The __Professional edition__ does not require any license key and can be used free of charge. The only functional difference from the Enterprise edition is a limitation of the maximum number of [build configurations](build-configuration.md). The limit is 100 build configurations. It can be extended by 10 with each agent license key added. You can install several servers with the Professional license.
+The __Professional edition__ does not require any license key and can be used free of charge. The only functional difference from the Enterprise edition is a limitation of the maximum number of [build configurations](managing-builds.md). The limit is 100 build configurations. It can be extended by 10 with each agent license key added. You can install several servers with the Professional license.
The __Enterprise edition__ requires a license key, has no limit on the number of build configurations and entitles you to TeamCity [support](feedback.md) from JetBrains for the maintenance period of the license, provided you use a [recent TeamCity version](teamcity-release-cycle.md).
@@ -150,7 +150,7 @@ The TeamCity Licensing Policy does not impose any limitations on the number of i
The Enterprise edition has no limit on the number of build configurations.
-The Professional edition allows 100 [build configurations](build-configuration.md) per server. Each build agent license key gives you 10 more build configurations in Professional edition in addition to one more agent. All build configurations are counted (i.e. including those in archived projects).
+The Professional edition allows 100 [build configurations](managing-builds.md) per server. Each build agent license key gives you 10 more build configurations in Professional edition in addition to one more agent. All build configurations are counted (i.e. including those in archived projects).
### Number of Agents
diff --git a/topics/managing-builds.md b/topics/managing-builds.md
new file mode 100644
index 000000000..93d0c4613
--- /dev/null
+++ b/topics/managing-builds.md
@@ -0,0 +1,12 @@
+[//]: # (title: Managing Builds)
+[//]: # (auxiliary-id: Managing Builds;Build Configuration)
+
+This section contains articles related to managing existing build configurations in TeamCity. Refer to the sidebar to see its contents.
+
+To learn how to create and configure them, go to [this section](creating-and-editing-build-configurations.md).
+
+
+
+ Creating and Editing Build Configurations
+
+
diff --git a/topics/managing-projects-and-build-configurations.md b/topics/managing-projects-and-build-configurations.md
deleted file mode 100644
index 8fbdd6b2a..000000000
--- a/topics/managing-projects-and-build-configurations.md
+++ /dev/null
@@ -1,16 +0,0 @@
-[//]: # (title: Managing Projects and Build Configurations)
-[//]: # (auxiliary-id: Managing Projects and Build Configurations)
-
-[Projects](project.md) and their entities in TeamCity can be configured:
-* via the web UI
-* using the [REST API](https://www.jetbrains.com/help/teamcity/rest/teamcity-rest-api-documentation.html)
-* programmatically using DSL based on the Kotlin language if the [versioned settings](storing-project-settings-in-version-control.md) feature is enabled
-
-Refer to the sidebar for the list of detailed instructions on managing projects and build configurations in TeamCity.
-
-
-
- Project
- Build Configuration
-
-
\ No newline at end of file
diff --git a/topics/managing-roles-and-permissions.md b/topics/managing-roles-and-permissions.md
index f7db358c0..33a82e3a8 100644
--- a/topics/managing-roles-and-permissions.md
+++ b/topics/managing-roles-and-permissions.md
@@ -170,7 +170,7 @@ __Agent manager__
|
-Can customize and manage [Build Agents](build-agent.md), change the run configuration policy, [enable/disable](build-agents-configuration-and-maintenance.md#Enabling%2FDisabling+Agents+via+UI) build agents, and [pause/resume build queue](build-queue.md#Pausing%2FResuming+Build+Queue).
+Can customize and manage [Build Agents](build-agent.md), change the run configuration policy, [enable/disable](build-agents-configuration-and-maintenance.md#Enabling%2FDisabling+Agents+via+UI) build agents, and [pause/resume build queue](working-with-build-queue.md#Pausing+and+Resuming+Build+Queue).
|
diff --git a/topics/maven-related-data.md b/topics/maven-related-data.md
deleted file mode 100644
index 8485d8d5a..000000000
--- a/topics/maven-related-data.md
+++ /dev/null
@@ -1,11 +0,0 @@
-[//]: # (title: Maven-related Data)
-[//]: # (auxiliary-id: Maven-related Data)
-
-## Maven Project Data
-
-In TeamCity you can find information about settings specified in your Maven project's `pom.xml` file on the dedicated __Maven__ tab of build configuration. In addition to getting a quick overview of the settings, you can find __Provided parameters__ in the upper section of this page, for example, `maven.project.name`, `maven.project.groupId`, `maven.project.version`, `maven.project.artifactId`. You can use these parameters within your build. You can reference them within the build number pattern using the `%`-notation. For example, `%\maven.project.version%.{0}`.
-
-## Maven Build Information
-
-For each Maven build TeamCity agent gathers Maven specific build details, that are displayed on the __Maven Build Info__ tab of the build results after the build is finished.
-This page can be useful for build engineers when adjusting build configurations.
diff --git a/topics/mercurial.md b/topics/mercurial.md
index 339ca5d4a..c8028cb75 100644
--- a/topics/mercurial.md
+++ b/topics/mercurial.md
@@ -10,7 +10,7 @@ Mercurial is to be installed on the server machine and, if the [agent-side check
Note that:
* __Remote Run__ from IDE is not supported. Please use [Branch Remote Run Trigger](branch-remote-run-trigger.md) instead.
-* Checkout rules for agent-side checkout are not supported except for the `.=>` rule.
+* Checkout rules for agent-side checkout are not supported except for the `.=>` rule.
For common VCS Root properties, see [this section](configuring-vcs-roots.md#Common+VCS+Root+Properties). The section below contains the description of Mercurial-specific fields and options.
TeamCity supports Mercurial out of the box.
diff --git a/topics/net.md b/topics/net.md
index b47a26847..ec2e9c565 100644
--- a/topics/net.md
+++ b/topics/net.md
@@ -388,7 +388,9 @@ MSBuild version
-Specify the version of the installed MSBuild engine. See the [Requirements](#Requirements) section for more details.
+Specify the version of the installed MSBuild engine. To ensure that a specific version of native MSBuild is used (for example, in a Docker container), you need to set the path to `MSBuild.exe` in the `PATH` environment variable.
+
+See the [Requirements](#Requirements) section for more details.
If you set the version in this field and choose to run the current step using Docker (with [Docker Wrapper](docker-wrapper.md)), make sure to specify the path to `MSBuild.exe` in the `PATH` environment variable. This way, the .NET runner will be able to find the required executable file even within the Docker container.
diff --git a/topics/ordering-build-queue.md b/topics/ordering-build-queue.md
deleted file mode 100644
index de0dcd056..000000000
--- a/topics/ordering-build-queue.md
+++ /dev/null
@@ -1,60 +0,0 @@
-[//]: # (title: Ordering Build Queue)
-[//]: # (auxiliary-id: Ordering Build Queue)
-
-This page lists the options to manage the queue builds manually. Automatic build queue optimization is detailed in the [separate section](build-queue.md#Build+Queue+Optimization+by+TeamCity).
-
-## Manually Reordering Builds in Queue
-
-To reorder builds in the [Build Queue](build-queue.md), you can drag them to the desired position.
-
-### Moving Builds to Top
-
-* For any queued build, do one of the following:
- * On the **[Build Queue](build-queue.md)** page, click the arrow button next to the build sequence number  to move the build to the top of the queue.
- * Click the build number or build status link anywhere in the UI, and, on the [queued build ](working-with-build-results.md)page, click the __Actions__ menu in the top right. Select the __Move to top__ action. The queue position will change. For a composite build, the whole build chain will be moved to the top of the queue.
- * For a running composite build which has dependencies that have not yet started, click the build number or build status link anywhere in the UI, and, on the [running build](working-with-build-results.md) page, click the __Actions__ menu in the top right. Select the __Move queued dependencies to top__ action. All queued dependencies of this build will be moved to the top of the queue.
-
-## Managing Build Priorities
-
-By default, builds are placed in the build queue in the order they are triggered: most recently triggered build is add to the bottom of the queue. It is possible to change build's priorities so that builds are inserted into the build queue at a position depending on their defined priority and the wait time of the currently queued builds.
-
-In TeamCity you can control build priorities by creating _Priority Classes_. A priority class is a set of build configurations with a specified priority (the higher the number, the higher the priority. For example, `priority=2` is higher than `priority=1`). The higher priority a configuration has, the higher place it gets when added to the Build Queue.
-To access these settings, on the __Build Queue__ tab, click the __Configure Build Priorities__ link in the upper right corner of the page.
-
-
-
-Note that only users with the __System Administrator__ role can manage build priority classes.
-
-
-By default, there are two predefined priority classes: _Personal_ and _Default_, both with `priority=0`.
-* All personal builds ([Remote Run](remote-run.md) or [Pre-tested Commit](pre-tested-delayed-commit.md)) are assigned to the _Personal_ priority class once they are added to the build queue. Note that you can change the priority for personal builds here.
-* The _Default_ class includes all the builds not associated with any other class. This allows creating a class with priority lower than default and place some builds to the bottom of the queue.
-
-To create a new priority class:
-1. Click __Create new priority class__.
-2. Specify its name, priority (in the range `-100..100`) and additional description. Click __Create__.
-3. Click the __Add configurations__ link to specify which build configurations should have priority defined in this class.
-
-This setting is taken into account only when a build is added to the queue. To ensure that builds with lower priority always have a chance to run, TeamCity also considers how long each build is staying in the queue. This allows running a long awaiting build with lower priority before the recently added builds with higher priority. For a detailed explanation of this behavior, refer to the [algorithm description](https://confluence.jetbrains.com/display/TW/Build+Queue+Priorities#BuildQueuePriorities-Algorithmdetails).
-
-## Removing Builds From Build Queue
-
-To remove build(s) from the queue, check the __Remove__ box next to the selected build and confirm the deletion. If a build to be removed from the queue is a part of a build chain, TeamCity shows the following message below the comment field: "This build is a part of a build chain". Refer to the [Build Chain](build-chain.md#Stopping%2FRemoving+From+Queue+Builds+from+Build+Chain) description for details.
-
-Additionally, you can:
-* Remove all your personal builds from the queue at once from the __Actions__ menu.
-* Remove several builds of [paused build configurations](build-configuration.md#Pausing+Several+Build+Configurations+in+Project) from the queue.
-
-## Limiting Maximum Size of Build Queue
-{product="tc"}
-
-It is possible to limit the maximum number of builds in the queue. By default, the limit is 6000 builds. The default value can be changed by configuring the `teamcity.buildTriggersChecker.queueSizeLimit` [internal property](server-startup-properties.md#TeamCity+Internal+Properties).
-
-When the queue size reaches the limit, TeamCity will pause [automatic build triggering](configuring-build-triggers.md). It will be reenabled once the queue size gets below limit. While triggering is paused, a warning message is displayed to all the users.
-However, even if the queue reached the limit and automatic triggering is paused, it is still possible to add builds to the queue [manually](running-custom-build.md).
-
-
-
- Build Queue
-
-
\ No newline at end of file
diff --git a/topics/ordering-projects-and-build-configurations.md b/topics/ordering-projects-and-build-configurations.md
index 2e550cd7b..5123be9fa 100644
--- a/topics/ordering-projects-and-build-configurations.md
+++ b/topics/ordering-projects-and-build-configurations.md
@@ -11,7 +11,7 @@ To add an individual project to the __Projects__ page or remove it from this pag
-Note that if a project has [archived subprojects](archiving-projects.md) / [paused build configurations](build-configuration.md#Pausing+Several+Build+Configurations+in+Project), they will also be displayed on the __Overview__ page and will be marked correspondingly.
+Note that if a project has [archived subprojects](archiving-projects.md) / [paused build configurations](changing-build-configuration-status.md#Pausing+Several+Build+Configurations+in+Project), they will also be displayed on the __Overview__ page and will be marked correspondingly.
diff --git a/topics/patterns-for-accessing-build-artifacts.md b/topics/patterns-for-accessing-build-artifacts.md
index 486404211..bc03e1cfb 100644
--- a/topics/patterns-for-accessing-build-artifacts.md
+++ b/topics/patterns-for-accessing-build-artifacts.md
@@ -25,7 +25,7 @@ __To download artifacts of the latest builds (last finished, successful or pinne
```
-__To download artifacts by the [build ID](working-with-build-results.md#Internal+Build+ID)__, use:
+__To download artifacts by the [build ID](build-results-page.md#Internal+Build+ID)__, use:
```Shell
/repository/download/BUILD_TYPE_EXT_ID/BUILD_ID:id/ARTIFACT_PATH
@@ -56,7 +56,7 @@ __To download all artifacts in a .zip archive__, use:
where
* `BUILD_TYPE_EXT_ID` is a [build configuration ID](configuring-general-settings.md).
-* `BUILD_SPECIFICATION` can be `.lastFinished`, `.lastSuccessful` or `.lastPinned`, specific `buildNumber` or [build ID](working-with-build-results.md#Internal+Build+ID) in format `BUILD_ID:id`.
+* `BUILD_SPECIFICATION` can be `.lastFinished`, `.lastSuccessful` or `.lastPinned`, specific `buildNumber` or [build ID](build-results-page.md#Internal+Build+ID) in format `BUILD_ID:id`.
* `ARTIFACT_PATH` is a path to the artifact on the TeamCity server. This path can contain a `{build.number}` pattern (`%7Bbuild.number%7D`) which will be replaced by TeamCity with the build number of the build whose artifact is retrieved. By default, the archive with all artifacts does not include [hidden artifact](build-artifact.md#Hidden+Artifacts). To include them, add `?showAll=true` at the end of the corresponding URL.
To download artifact from the last finished, last successful, last pinned or tagged build in a specific branch, add the `?branch=` parameter at the end of the corresponding URL.
@@ -72,7 +72,7 @@ TeamCity allows obtaining a file from an archive from the build artifacts direct
```
* __`BUILD_TYPE_EXT_ID`__ is a [build configuration ID](configuring-general-settings.md).
-* __`BUILD_SPECIFICATION`__ can be `.lastFinished`, `.lastPinned`, `.lastSuccessful`, specific `buildNumber` or [build ID](working-with-build-results.md#Internal+Build+ID) in format `BUILD_ID:id`.
+* __`BUILD_SPECIFICATION`__ can be `.lastFinished`, `.lastPinned`, `.lastSuccessful`, specific `buildNumber` or [build ID](build-results-page.md#Internal+Build+ID) in format `BUILD_ID:id`.
* __`PATH_WITHIN_ARCHIVE`__ is a path to a file within a `zip/7-zip/jar/tar.gz` archive on TeamCity server.
Following archive types are supported (case-insensitive):
* `.zip`
diff --git a/topics/perforce-shelve-trigger.md b/topics/perforce-shelve-trigger.md
index 7f9132676..d563156ab 100644
--- a/topics/perforce-shelve-trigger.md
+++ b/topics/perforce-shelve-trigger.md
@@ -11,7 +11,7 @@ The trigger supports Perforce 2018.2 or later.
## Trigger Settings
-The trigger monitors all [Perforce VCS roots](perforce.md) associated with the current [build configuration](build-configuration.md). You can filter monitored changelists by their description. To do this, specify the required keyword to search.
+The trigger monitors all [Perforce VCS roots](perforce.md) associated with the current [build configuration](managing-builds.md). You can filter monitored changelists by their description. To do this, specify the required keyword to search.
>See how to invoke this trigger [via TeamCity REST API](https://www.jetbrains.com/help/teamcity/rest/edit-build-configuration-settings.html#Manage+Build+Triggers).
diff --git a/topics/personal-build.md b/topics/personal-build.md
index cb5e193fd..93c554950 100644
--- a/topics/personal-build.md
+++ b/topics/personal-build.md
@@ -1,9 +1,9 @@
-[//]: # (title: Personal Build)
-[//]: # (auxiliary-id: Personal Build)
+[//]: # (title: Running Personal Build)
+[//]: # (auxiliary-id: Running Personal Build;Personal Build)
A _personal build_ is a build-out of the common build sequence which typically uses the changes not yet committed into the version control. Personal builds are usually initiated from one of the [supported IDEs](supported-platforms-and-environments.md#Remote+Run+and+Pre-tested+Commit) via the [Remote Run](remote-run.md) procedure. You can also upload a patch with changes directly to the server, as described [below](#Direct+Patch+Upload).
-A personal build uses the current VCS repository sources plus the changed files identified during the remote run initiation. The results of a personal build can be seen in the "My Changes" view of the corresponding IDE plugin and on the __[Changes](viewing-your-changes.md)__ page in TeamCity. Finished personal builds are listed in the [build history](build-history.md), but only for the users who initiated them.
+A personal build uses the current VCS repository sources plus the changed files identified during the remote run initiation. The results of a personal build can be seen in the "My Changes" view of the corresponding IDE plugin and on the __[Changes](viewing-user-changes-in-builds.md)__ page in TeamCity. Finished personal builds are listed in the [build history](build-results-page.md#Build+History+in+Classic+UI), but only for the users who initiated them.
Read more about running commits via Remote Run in [Pre-Tested (Delayed) Commit](pre-tested-delayed-commit.md).
By default, users only see their own personal builds in the build lists, but this can be changed via the "_Show all personal builds_" option in __Your Profile | General | UI settings__ of the [user profile](configuring-your-user-profile.md).
@@ -17,28 +17,22 @@ It is possible to [restrict running personal builds](configuring-general-setting
Users with the _Change build source code with a custom patch_ permission can upload a patch with local changes directly to the TeamCity server, via our web UI or REST API.
-TeamCity supports patches in a [unified diff format](https://en.wikipedia.org/wiki/Diff#Unified_format).
+TeamCity supports patches in a [unified diff format](https://en.wikipedia.org/wiki/Diff#Unified_format).
+Since the format varies between tools that can generate unidiff files, we cannot guarantee error-free processing of all unidiff variations. Currently, TeamCity provides a stable parsing of unidiff files generated by IntelliJ Platform IDEs and Git.
+TeamCity does not support binary changes in non-binary files.
-
-
-* Since the format varies between tools that can generate unidiff files, we cannot guarantee error-free processing of all unidiff variations. Currently, TeamCity provides a stable parsing of unidiff files generated by IntelliJ Platform IDEs and Git.
-
-* TeamCity does not support binary changes in non-binary files.
-
-
-
-__To generate a patch__:
+To generate a patch:
* __In any IntelliJ Platform IDE__: select the required local changes in the commit log, click [Create Patch](https://www.jetbrains.com/help/idea/use-patches.html#create-patch) in the context menu, and save the patch as a `*.diff` file.
* __Via Git__: run `git diff commit1..commit2 > path/filename.diff`.
For example, to save a diff between the last commit and the preceding commit to the `patch.diff` file in the `test` directory, run `git diff HEAD^ HEAD > ~/test/patch.diff`. See other examples in [Git documentation](https://git-scm.com/docs/git-diff#_examples).
-__To upload a patch and run a personal build via the web UI__:
+To upload a patch and run a personal build via the web UI:
1. Open the [Run Custom Build](running-custom-build.md) dialog and enable the "_run as a personal build_" option. The __Upload patch__ button will appear. 
2. Upload the patch and click __Run Build__.
The agent will receive the patch and apply it before running the build. After the build, it will revert the patch, so the checkout directory can be reused by subsequent builds.
-__To upload a patch and run a personal build via REST API__:
+To upload a patch and run a personal build via REST API:
1. Send the following `POST` request:
```Shell
@@ -82,7 +76,7 @@ If the current build configuration has a [Perforce VCS root](perforce.md), you c
IntelliJ Platform Plugin
Eclipse Plugin
- Visual Studio Addin
+ Visual Studio Add-in
Pre-tested Commit
diff --git a/topics/pre-tested-delayed-commit.md b/topics/pre-tested-delayed-commit.md
index ce4457fe4..160838326 100644
--- a/topics/pre-tested-delayed-commit.md
+++ b/topics/pre-tested-delayed-commit.md
@@ -11,7 +11,7 @@ The pre-tested commit is initiated via a plugin to one of [supported IDEs](suppo
For Git and Mercurial the recommended way to use [Branch Remote Run Trigger](branch-remote-run-trigger.md) approach to run personal builds off branches.
-## Matching changes and build configurations
+## Matching Changes and Build Configurations
[//]: # (Internal note. Do not delete. "Pre-Tested \(Delayed\) Commitd256e43.txt")
@@ -31,11 +31,11 @@ This includes:
If upon changed files choosing TeamCity is unable to find build configurations that the files can be sent to, the option to initiate the personal build will not be available.
-## General Flow of a pre-tested commit
+## General Flow of Pre-tested Commit
* A developer uses the Remote Run dialog of a [TeamCity IDE plugin](installing-tools.md) to select the files to be sent to TeamCity.
* Based on the selected files, a list of applicable build configurations is displayed. The developer selects the build configurations to test the change against and sets options for a pre-tested commit.
-* The TeamCity IDE plugin builds a "patch" - full content of all the files selected and sends it to the TeamCity server. The patch is also preserved locally on the developer's machine. When sent, the change appears on the developer's [changes](viewing-your-changes.md) page. Developer can continue working with the code and can modify the files sent to the pre-tested commit.
+* The TeamCity IDE plugin builds a "patch" - full content of all the files selected and sends it to the TeamCity server. The patch is also preserved locally on the developer's machine. When sent, the change appears on the developer's [changes](viewing-user-changes-in-builds.md) page. Developer can continue working with the code and can modify the files sent to the pre-tested commit.
* The personal build is queued and processed like other queued builds.
* When the build starts, it checks out the latest sources just like a normal build and then applies the developer's personal changes sent from the IDE over (full file content is used)
* The build runs as usual
@@ -43,7 +43,6 @@ If upon changed files choosing TeamCity is unable to find build configurations t
* The TeamCity IDE plugin pings the TeamCity server to check if all the selected build configurations have personal builds ready. If a build fails, a notification is displayed in the IDE and the process ends.
* If all the personal builds finish successfully, the IDE plugin displays a progress, backs up the current version of the files participating in the personal change (as they might already be modified since the pre-tested commit was initiated), then restores the file contents from the saved "patch", performs the version control commit (reports an error if there was an error like a VCS conflict) and restores the just backed up files to bring the working copy in the last seen state. The pre-tested commit in the TeamCity plugin window gets an error or success mark.
-
IntelliJ Platform Plugin
diff --git a/topics/predefined-build-parameters.md b/topics/predefined-build-parameters.md
index 0768808e7..6c7445396 100644
--- a/topics/predefined-build-parameters.md
+++ b/topics/predefined-build-parameters.md
@@ -960,7 +960,7 @@ dep..
If there are multiple `dep..` paths to the same build configuration with `btID`, so that different builds are accessible via (direct or indirect) artifact dependencies, the following rules apply:
* If there is a snapshot dependency between some of the builds, the build from the same chain wins.
-* If there are no snapshot dependencies and multiple builds are accessible only via an artifact dependency, the build with a larger [build ID](working-with-build-results.md#Internal+Build+ID) wins. If there are several artifact dependencies from a single build configuration, only the first one is considered.
+* If there are no snapshot dependencies and multiple builds are accessible only via an artifact dependency, the build with a larger [build ID](build-results-page.md#Internal+Build+ID) wins. If there are several artifact dependencies from a single build configuration, only the first one is considered.
>When using build parameters of the _Password_ type, referencing them from a dependency, such as `%dep..password_parameter%`, will not retrieve the actual value. This is done for security reasons: to prevent dependencies from accessing the value, thus restricting the possibility of unauthorized access to it.
@@ -1004,7 +1004,7 @@ If build configurations A and B are trying to set different values for the same
* Medium priority: if a value is redefined in a set of builds via `[prefix]*[suffix]`. Among them, the longer values are considered more specific and thus have higher priority than the shorter ones.
* Low priority: if a value is redefined in all preceding builds via `*`.
-The `reverse.dep.*` parameters are processed on queuing the build where these parameters are defined. As the parameters' values should be known at that stage, they should be defined only either as [build configuration parameters](configuring-build-parameters.md#Custom+Build+Parameters) or in the [custom build dialog](running-custom-build.md#Run+Custom+Build+dialog). Setting the parameter during the build steps has no effect.
+The `reverse.dep.*` parameters are processed on queuing the build where these parameters are defined. As the parameters' values should be known at that stage, they should be defined only either as [build configuration parameters](configuring-build-parameters.md#Custom+Build+Parameters) or in the [custom build dialog](running-custom-build.md). Setting the parameter during the build steps has no effect.
>Pushing a new parameter into a build will override the "_[Do not run new build if there is a suitable one](snapshot-dependencies.md#Suitable+Builds)_" snapshot dependency option and may trigger a new build if the parameter is set to a non-default value.
diff --git a/topics/project-home-page.md b/topics/project-home-page.md
new file mode 100644
index 000000000..cd78d5ab1
--- /dev/null
+++ b/topics/project-home-page.md
@@ -0,0 +1,23 @@
+[//]: # (title: Project Home Page)
+[//]: # (auxiliary-id: Project Home Page)
+
+This article gives an overview of the __Project Home__ page of the new TeamCity UI. Most of its features are also available in the classic UI mode.
+
+The __Project Home__ page allows viewing the main information about the builds of the current project and its subprojects. It also gives quick access to most popular actions for managing builds.
+
+This page has the following tabs:
+* __Overview__: gives a preview of the project's nested subprojects and build configurations. It has two main view modes: __Builds__ (a hierarchy of build lists) and __Trends__ (interactive graphs to preview the builds' trends and apply quick actions). When viewing trends, you can hover over any chart bar to instantly see more information about the respective build: its duration, queue statistics, test results, used agent, and more.
+ This tab also allows you to quickly create nested projects down the hierarchy and configure favorite projects.
+* __Investigations__: shows active [problem investigations](investigating-and-muting-build-failures.md) in the current project.
+* __Change Log__: shows a detailed visual change log of the current project.
+* __Statistics__: shows [custom statistics charts](custom-chart.md) of the current project.
+* __Current Problems__: shows the actual [build failures and failed tests](viewing-tests-and-configuration-problems.md) of the current project.
+* __Muted Problems__: shows what build problems have been [muted](investigating-and-muting-build-failures.md#Muting+Build+Problems) in the current project.
+* __Build Chains__: if the current project has [build chains](build-chain.md), shows their details and graphs (currently, this page uses the classic UI approach for visualization).
+* __Flaky Tests__: shows [flaky tests](viewing-tests-and-configuration-problems.md#Flaky+Tests) of the current project.
+
+From __Project Home__, you can switch to other view modes:
+* To switch to __Project Settings__, use the __Edit project__ link in the upper right corner. To access a particular section of the settings, open the context menu to the right of this link.
+* To open __Build Configuration Home__ of a particular nested build configuration, click its name in the list or its trends card.
+* To open __Build Results__ of a particular build, expand its build configuration in a list and click the build's number. Or, when in the __Trends__ mode, click the respective bar on a chart. Note that only a limited number of most recent builds are displayed in the __Project Home__ mode. To see more builds, open the __Build Configuration Home__ view.
+
diff --git a/topics/project.md b/topics/project.md
index 033c97eb8..e7b5fa734 100644
--- a/topics/project.md
+++ b/topics/project.md
@@ -1,7 +1,7 @@
[//]: # (title: Project)
[//]: # (auxiliary-id: Project)
-A _project_ in TeamCity is a collection of [build configurations](build-configuration.md). A TeamCity project can correspond to a software project, a specific version/release of a project or any other logical group of the build configurations.
+A _project_ in TeamCity is a collection of [build configurations](managing-builds.md). A TeamCity project can correspond to a software project, a specific version/release of a project or any other logical group of the build configurations.
The project has a name, an [ID](identifier.md), and an optional description.
In TeamCity, user [roles and permissions](managing-roles-and-permissions.md) are managed on a per-project basis.
@@ -55,10 +55,9 @@ The root project is special in the following ways:
- Build Configuration
+ Build Configuration
- Managing Projects and Build Configurations
Creating and Editing Projects
Creating and Editing Build Configurations
Project Export
diff --git a/topics/python.md b/topics/python.md
index 7f51350ac..2fe60b427 100644
--- a/topics/python.md
+++ b/topics/python.md
@@ -124,7 +124,7 @@ Unittest
-Launch the [unittest](https://docs.python.org/3/library/unittest.html) framework. The unit test results will be displayed on the __[Tests](working-with-build-results.md#Tests)__ tab of __Build Results__.
+Launch the [unittest](https://docs.python.org/3/library/unittest.html) framework. The unit test results will be displayed on the __[Tests](build-results-page.md#Tests+Tab)__ tab of __Build Results__.
To filter the scope of processed files, you can specify the path to unit test file(s) in the additional arguments.
@@ -148,7 +148,7 @@ Pytest
|
-Launch the [pytest](https://docs.pytest.org/en/stable/index.html) framework. The test results will be displayed on the __[Tests](working-with-build-results.md#Tests)__ tab of __Build Results__.
+Launch the [pytest](https://docs.pytest.org/en/stable/index.html) framework. The test results will be displayed on the __[Tests](build-results-page.md#Tests+Tab)__ tab of __Build Results__.
To filter the scope of processed files, you can specify the path to pytest file(s) in the additional arguments.
@@ -172,7 +172,7 @@ Flake8
|
-Launch the [Flake8](https://pypi.org/project/flake8/) wrapper. The code inspection results will be displayed on the __[Code Inspection](working-with-build-results.md#Code+Inspection+Results)__ tab of __Build Results__.
+Launch the [Flake8](https://pypi.org/project/flake8/) wrapper. The code inspection results will be displayed on the __[Code Inspection](build-results-page.md#Code+Inspection+Tab)__ tab of __Build Results__.
To filter the scope of processed files, you can specify the path to Python file(s) in the additional arguments.
@@ -196,7 +196,7 @@ Pylint
|
-Launch the [Pylint](https://pypi.org/project/pylint/) tool. The code inspection results will be displayed on the __[Code Inspection](working-with-build-results.md#Code+Inspection+Results)__ tab of __Build Results__.
+Launch the [Pylint](https://pypi.org/project/pylint/) tool. The code inspection results will be displayed on the __[Code Inspection](build-results-page.md#Code+Inspection+Tab)__ tab of __Build Results__.
To filter the scope of processed files, specify the path to Python file(s) in the additional arguments.
@@ -317,7 +317,7 @@ Coverage
|
-Enable code coverage collecting via [Coverage.py](https://coverage.readthedocs.io/en/coverage-5.3/). TeamCity displays the produced test report on the __[Code Coverage](working-with-build-results.md#Code+Coverage+Results)__ tab.
+Enable code coverage collecting via [Coverage.py](https://coverage.readthedocs.io/en/coverage-5.3/). TeamCity displays the produced test report on the __[Code Coverage](build-results-page.md#Code+Coverage+Tab)__ tab.
| |
diff --git a/topics/rake.md b/topics/rake.md
index eefbe1e93..a8a0f1e74 100644
--- a/topics/rake.md
+++ b/topics/rake.md
@@ -27,9 +27,10 @@ To use the [minitest](https://rubygems.org/gems/minitest) framework, the `minite
## Important Notes
-* Ruby's _pending specs_ are shown as __Ignored Tests__ in the __Overwiew__ tab.
+
+* Ruby's _pending specs_ are shown as __Ignored Tests__ in the __Overview__ tab.
* Rake Runner uses its own unit tests runner and loads it using the `RUBYLIB` environment variable. You need to ensure your program doesn't clear this environment variable, but you may append your paths to it.
-* If you run RSpec with the `--color` option enabled under Windows OS, RSpec will suggest you install the __win32console__ gem. This warning will appear in your build log, but you can ignore it. TeamCity Rake Runner doesn't support coloured output in the build log and doesn't use this feature.
+* If you run RSpec with the `--color` option enabled under Windows OS, RSpec will suggest you install the __win32console__ gem. This warning will appear in your build log, but you can ignore it. TeamCity Rake Runner doesn't support coloured output in the build log and does not use this feature.
* Rake Runner runs spec examples with a custom formatter. If you use additional console formatter, your build log will contain redundant information.
* `Spec::Rake::SpecTask.spec_opts` of your rakefile is affected by `SPEC_OPTS` command line parameter. Rake Runner always uses `SPEC_OPTS` to set up its custom formatter. Thus, you should set up Spec Options in Web UI. The same limitation exists for Cucumber tests options.
* To include HTML reports into the build results, you can add the corresponding [report tab](including-third-party-reports-in-the-build-results.md) for them.
@@ -240,7 +241,7 @@ Attached reporters
-If you want TeamCity to display the test results on a dedicated [Tests tab](working-with-build-results.md#All+Tests) of the __Build Results__ page, select here the testing framework you use: Test::Unit, Test-Spec, Shoulda, RSpec or Cucumber.
+If you want TeamCity to display the test results on a dedicated [Tests tab](build-results-page.md#Tests+Tab) of the __Build Results__ page, select here the testing framework you use: Test::Unit, Test-Spec, Shoulda, RSpec or Cucumber.
diff --git a/topics/remote-run.md b/topics/remote-run.md
index 70971a933..6c40951a9 100644
--- a/topics/remote-run.md
+++ b/topics/remote-run.md
@@ -3,14 +3,14 @@
A _remote run_ is a [personal build](personal-build.md) initiated by a developer from one of the supported IDE plugins to test how the changes will integrate into the project's code base. Unlike [Pre-tested (delayed) commit](pre-tested-delayed-commit.md), no code is checked into the VCS regardless of the state of the personal build initiated via Remote Run.
-For a list of version control systems supported by each IDE, see [Supported Platforms and Environments](supported-platforms-and-environments.md).
+For a list of version control systems supported by each IDE, see [Supported Platforms and Environments](supported-platforms-and-environments.md#IDE+Integration).
IntelliJ Platform Plugin
Eclipse Plugin
- Visual Studio Addin
+ Visual Studio Add-in
Pre-tested (delayed) commit
diff --git a/topics/rest-api-reference.md b/topics/rest-api-reference.md
index cc99d0ff2..78b171b2f 100644
--- a/topics/rest-api-reference.md
+++ b/topics/rest-api-reference.md
@@ -820,7 +820,7 @@ curl -v --basic --user : --request PUT http://
The most frequently used values for `` are `id:` and `name:`.
-__Since TeamCity 2017.2__, the _experimental_ [type](build-configuration.md#Build+Configuration+Types) locator is supported with one of the values: `regular`, `composite`, or `deployment`.
+__Since TeamCity 2017.2__, the _experimental_ [type](managing-builds.md#Build+Configuration+Types) locator is supported with one of the values: `regular`, `composite`, or `deployment`.
Other supported [dimensions](https://www.jetbrains.com/help/teamcity/rest/teamcity-rest-api-documentation.html#Locator) are (these are in _experimental_ state):
* `internalId` — internal ID of the build configuration.
@@ -898,7 +898,7 @@ Using a [locator](https://www.jetbrains.com/help/teamcity/rest/teamcity-rest-api
For some requests, a default filtering is applied which returns only "normal" builds (finished builds which are not canceled, not failed-to-start, not personal, and on default branch (in branched build configurations)), unless those types of builds are specifically requested via the locator. To turn off this default filter and process all builds, add the `defaultFilter:false` dimension to the build locator. Default filtering varies depending on the specified locator dimensions. For example, when `agent` or `user` dimensions are present, personal, canceled, and failed to start builds are included into the results.
Examples of supported build locators:
-* `id:` — use [internal build ID](working-with-build-results.md#Internal+Build+ID) when you need to refer to a specific build.
+* `id:` — use [internal build ID](build-results-page.md#Internal+Build+ID) when you need to refer to a specific build.
* `number:` — to find build by build number, provided build configuration is already specified.
* `:,:` — to find builds by multiple criteria.
diff --git a/topics/revision.md b/topics/revision.md
index cb50e02dc..7a22767e4 100644
--- a/topics/revision.md
+++ b/topics/revision.md
@@ -5,10 +5,10 @@ A _revision_ refers to a specific state of a version control history; basically
When displaying [changes](change.md) included in a finished or queued build, TeamCity also displays the corresponding revision. This page explains how TeamCity chooses VCS revisions for a build.
-TeamCity remembers the current repository revision when you add a new [VCS root](vcs-root.md) for a [project](project.md) or [build configuration](build-configuration.md), or when you [modify settings](configuring-vcs-settings.md) of an existing VCS root.
+TeamCity remembers the current repository revision when you add a new [VCS root](vcs-root.md) for a [project](project.md) or [build configuration](managing-builds.md), or when you [modify settings](configuring-vcs-settings.md) of an existing VCS root.
After that, TeamCity does not monitor the whole repository but only collects changes for the scope of the repository specified in TeamCity: the configured [VCS root settings](configuring-vcs-settings.md) with [checkout rules](vcs-checkout-rules.md).
-The revision of the sources corresponding to the latest detected change affecting your build will be displayed as the VCS root revision on the [Changes page](viewing-your-changes.md) accessible via the link on the __Projects__ page or on the [Changes tab](working-with-build-results.md#Changes) of __Build Results__.
+The revision of the sources corresponding to the latest detected change affecting your build will be displayed as the VCS root revision on the [Changes page](viewing-user-changes-in-builds.md) accessible via the link on the __Projects__ page or on the [Changes tab](build-results-page.md#Changes+Tab) of __Build Results__.
## Revision order
@@ -24,7 +24,7 @@ If the settings of a VCS root get modified since the last detected change, the r
Change
- Build Configuration
+ Build Configuration
Investigating and Muting Build Failures
diff --git a/topics/run-configuration-policy.md b/topics/run-configuration-policy.md
deleted file mode 100644
index de0110d5a..000000000
--- a/topics/run-configuration-policy.md
+++ /dev/null
@@ -1,10 +0,0 @@
-[//]: # (title: Run Configuration Policy)
-[//]: # (auxiliary-id: Run Configuration Policy)
-
-The run configuration policy allows you to select the specific build configurations you want a build agent to run. By default, build agents run all compatible build configurations and this isn't always desirable. The run configuration policy settings are located on the __Compatible configurations__ tab of the __[Agents Details](viewing-build-agent-details.md)__ page.
-
-
-
- Assigning Build Configurations to Specific Build Agents
-
-
\ No newline at end of file
diff --git a/topics/running-custom-build.md b/topics/running-custom-build.md
index 23b5006ec..165615ab8 100644
--- a/topics/running-custom-build.md
+++ b/topics/running-custom-build.md
@@ -7,29 +7,27 @@ Besides triggering a build automatically, TeamCity allows you to run a build man
There are several ways of launching a custom build in TeamCity:
* Click the ellipsis on the __Run__ button, and specify the options in the __Run Custom Build__ dialog described [below](#General+Options).
-* To run a custom build with specific changes, open the build results page, go to the __[Changes](working-with-build-results.md#Changes)__ tab, expand the required change, click the __Run build with this change__, and proceed with the [options](#General+Options) in the __Run Custom Build__ dialog.
+* To run a custom build with specific changes, open the build results page, go to the __[Changes](build-results-page.md#Changes+Tab)__ tab, expand the required change, click the __Run build with this change__, and proceed with the [options](#General+Options) in the __Run Custom Build__ dialog.
* Use [HTTP request](accessing-server-by-http.md) or [REST API request](https://www.jetbrains.com/help/teamcity/rest/edit-build-configuration-settings.html#Manage+Build+Triggers) to TeamCity to trigger a build.
* [Promote a build](#Promoting+Build).
* [Build triggers](configuring-build-triggers.md) can launch builds with custom parameters.
-## Run Custom Build dialog
-
-### General Options
+## General Options
Select an agent you want to run the build on from the drop-down menu. Note that for each agent in the list, TeamCity displays its current state and estimates when the agent will become idle if it is running a build at the moment. Besides the possibility to run a build on a particular agent from the list, you can also use one of the following options:
-* __fastest idle agent__: _default option_; if selected, TeamCity will automatically choose an agent to run a build on based on calculated estimates.
-* __the fastest agent in <a certain> pool__: if selected, TeamCity will run a build on an agent from a specified pool
+* __Fastest idle agent__: _default option_; if selected, TeamCity will automatically choose an agent to run a build on based on calculated estimates.
+* __Fastest agent in a certain pool__: if selected, TeamCity will run a build on an agent from a specified pool
* if [cloud integration](teamcity-integration-with-cloud-solutions.md) is configured, you can select to run a build on an agent from a __certain cloud image__. If no available cloud agents of this type exist, TeamCity will also attempt to start a new one.
{product="tc"}
-* __run a build on <a specified> agent__
+* __Run a build on <a specified> agent__
* __All enabled compatible agents__: Use this option to run a build simultaneously on all agents that are enabled and compatible with the build configuration. This option may be useful in the following cases:
- * run a build for agent maintenance purposes (for example, you can create a configuration to check whether agents function properly after an environment upgrade/update).
- * run a build on different platforms (for example, you can set up a configuration, and specify for it a number of compatible build agents with different environments installed).
+ * Run a build for agent maintenance purposes (for example, you can create a configuration to check whether agents function properly after an environment upgrade/update).
+ * Run a build on different platforms (for example, you can set up a configuration, and specify for it a number of compatible build agents with different environments installed).
On the __General__ options you can also specify whether
-* this build will be run as a [personal](personal-build.md) one
-* this build will be put at the top of the [build queue](build-queue.md)
-* all files in the [build checkout directory](build-checkout-directory.md) will be cleaned before this build.
+* This build will be run as a [personal](personal-build.md) one.
+* This build will be put at the top of the [build queue](working-with-build-queue.md)
+* All files in the [build checkout directory](build-checkout-directory.md) will be cleaned before this build.
* If snapshot dependencies are configured, this option can be applied to snapshot dependencies. In this case, all the builds of the build chain will be forced to use clean checkout.
@@ -41,7 +39,7 @@ If the current build configuration uses a [Perforce](perforce.md) VCS root, you
>Learn how to automate running builds on shelved files with [Perforce Shelve Trigger](perforce-shelve-trigger.md).
-### Dependencies
+## Dependencies
_This tab is available only for builds that have dependencies on other builds_.
You can enforce rebuilding of all dependencies and select a particular build whose artifacts will be taken. By default, the last 20 builds are displayed.
@@ -53,7 +51,7 @@ Note that if you re-run a dependent build, TeamCity will try to rebuild all depe
By default, dependency builds in the list are grouped by their branches sorted alphabetically. Builds of the same branch are sorted relatively to each other by date. In some cases, you might need to discard branch-based sorting and sort all dependency builds only by their date, to display the newest builds at the top. To do this, click __Sort dependencies by date__. To return to the default sorting, click __Reset all__.
-### Changes
+## Changes
_This tab is available only if you have permissions to access VCS roots for the build configuration._
The tab allows you to specify a particular change to be included to the build.
@@ -61,30 +59,30 @@ The tab allows you to specify a particular change to be included to the build.
The build will use the change's revision to check out the sources. That is, all the changes up to the selected one will be included into the build.
Note that TeamCity displays only the changes detected earlier for the current build configuration VCS roots. If the VCS root was detached from the build configuration after the change occurred, there is no ability to run the build on such a change. A limited number of changes is displayed. If there is an earlier change in TeamCity that you need to run a build on, you can locate the change in the Change Log and use the __Run build with this change__ action.
-### Include changes
+## Include Changes
The __Include changes__ drop-down menu allows selecting the changes in the VCS roots attached to the configuration to run the build on.
* __Latest changes at the moment the build is started__: TeamCity will automatically include all changes available at the moment.
* __Last change to include__: When you select a change in the drop-down menu, TeamCity runs the build with the selected change and all changes that were made before it. The build run with the changes earlier than the latest available is marked as a [history build](history-build.md).
-### Build branch
+## Build Branch
The __Build branch__ drop-down menu, available if you have branches in your build configuration (or in snapshot dependencies of this build configuration), allows choosing a branch to be used for the custom build.
-### Use settings
+## Use Settings
If your project has [versioned settings](storing-project-settings-in-version-control.md) enabled, you can tell TeamCity to run a build:
-* with the settings defined for the project, either the current settings on the server or the settings from VCS
-* with the project settings currently defined on the server
-* with the settings loaded from the VCS revision calculated for the build.
+* With the settings defined for the project, either the current settings on the server or the settings from VCS.
+* With the project settings currently defined on the server.
+* With the settings loaded from the VCS revision calculated for the build.
-If changes are selected in the [step above](#Include+changes), the revision of the project settings corresponding to the selected changes will be loaded.
+If changes are selected in the [step above](#Include+Changes), the revision of the project settings corresponding to the selected changes will be loaded.
To define which settings to take, use one of the corresponding options from the _Use settings_ drop-down menu (the option here will override the [project-level setting](storing-project-settings-in-version-control.md#Defining+Settings+to+Apply+to+Builds)).
-### Parameters
+## Parameters
@@ -98,9 +96,9 @@ When adding/editing/deleting properties and variables, note the following:
* Only newly added properties/variables can be deleted. You cannot delete predefined properties.
* Each parameter value must be no longer than 16,000 characters.
-### Comment and Tags
+## Comment and Tags
-Add an optional comment as well as one or more [tags](build-tag.md) to the build. You can also add a custom build to [favorites](favorite-build.md) by checking the corresponding box in this section.
+Add an optional comment as well as one or more [tags](build-actions.md#Add+Tags+to+Build) to the build. You can also add a custom build to [favorites](build-actions.md#Add+Build+to+Favorites) by checking the corresponding box in this section.
@@ -116,14 +114,14 @@ To promote a build, open the build results page of the dependency build and clic
For example, your build configuration A is configured to take artifacts from the last successful build of configuration B, but you want to run a build of configuration A using artifacts of a different build of configuration B (not the last successful build), so you promote an earlier build of B.
Build promotion affects only a single run of the dependent build. Once you click __Promote__, a build of the dependent build configuration which uses the artifacts of the specified build is queued. Any further runs of the dependent build configuration will use artifacts as configured (last successful, last pinned, and so on), unless you use another promotion.
-More details are available in the [related blog-post](http://blog.jetbrains.com/teamcity/2012/04/teamcity-build-dependencies-2/).
+More details are available in the [related blog post](http://blog.jetbrains.com/teamcity/2012/04/teamcity-build-dependencies-2/).
Upgrade
- Build Queue
+ Working with Build Queue
Dependent Build
Personal Build
diff --git a/topics/service-messages.md b/topics/service-messages.md
index 6ea038477..1098f606a 100644
--- a/topics/service-messages.md
+++ b/topics/service-messages.md
@@ -289,7 +289,7 @@ where:
### Reporting Tests
-To use the TeamCity on-the-fly test reporting, a testing framework needs dedicated support for this feature to work (alternatively, [XML Report Processing](xml-report-processing.md) can be used). If TeamCity doesn't support your testing framework natively, it is possible to modify your build script to report test runs to the TeamCity server using service messages. This makes it possible to display test results in real-time, make test information available on the __[Tests](working-with-build-results.md#All+Tests)__ tab of the __Build Results__ page.
+To use the TeamCity on-the-fly test reporting, a testing framework needs dedicated support for this feature to work (alternatively, [XML Report Processing](xml-report-processing.md) can be used). If TeamCity doesn't support your testing framework natively, it is possible to modify your build script to report test runs to the TeamCity server using service messages. This makes it possible to display test results in real-time, make test information available on the __[Tests](build-results-page.md#Tests+Tab)__ tab of the __Build Results__ page.
### Message Creation Timestamp
@@ -325,7 +325,7 @@ will result in
#### Supported Test ServiceMessages
-__Test suite messages:__ Test suites are used to group tests. TeamCity displays tests grouped by suites on the __[Tests](working-with-build-results.md#All+Tests)__ tab of the __Build Results__ page and in other places.
+__Test suite messages:__ Test suites are used to group tests. TeamCity displays tests grouped by suites on the __[Tests](build-results-page.md#Tests+Tab)__ tab of the __Build Results__ page and in other places.
```Shell
##teamcity[testSuiteStarted name='suiteName']
@@ -443,7 +443,7 @@ Integration Tests: Backend: org.jetbrains.teamcity.LoginPageController.testBadPa
// test parameters = ("incorrect password", false)
```
-The __[Tests](working-with-build-results.md#Tests)__ tab of the __Build Results__ page allows grouping by suites, packages/namespaces, classes, and tests. Usually the attribute values are provides as they are reported by your test framework and TeamCity is able to interpret test names correctly.
+The __[Tests](build-results-page.md#Tests+Tab)__ tab of the __Build Results__ page allows grouping by suites, packages/namespaces, classes, and tests. Usually the attribute values are provides as they are reported by your test framework and TeamCity is able to interpret test names correctly.
If a test cannot be parsed in the form above, TeamCity still tries to extract `` from the full test name for the filtering on the Tests tab, and treats everything after the suite a non-parsable test name.
diff --git a/topics/set-up-notifications.md b/topics/set-up-notifications.md
index e1f2315bf..26594abc7 100644
--- a/topics/set-up-notifications.md
+++ b/topics/set-up-notifications.md
@@ -13,7 +13,7 @@ In this guide, we show how to quickly configure email, browser, and Slack notifi
### Email Notifier
-First of all, the TeamCity server administrator should integrate TeamCity with the email service provider used in your organization. This can be done in __Administration | Email Notifier__ and requires entering parameters like SMTP host and service email.
+First, the TeamCity server administrator should integrate TeamCity with the email service provider used in your organization. This can be done in __Administration | Email Notifier__ and requires entering parameters like SMTP host and service email.
The email notifier will send notifications to the addresses specified in each user's profile, according to their [preferences](#Subscribe+to+Notifications).
diff --git a/topics/shared-resources.md b/topics/shared-resources.md
index 7087541cc..937808bb9 100644
--- a/topics/shared-resources.md
+++ b/topics/shared-resources.md
@@ -3,7 +3,7 @@
The _Shared Resources_ [build feature](adding-build-features.md) allows limiting concurrently running builds using a shared resource, such as an external (to the CI server) resource, _for example, a test database, or a server with a limited number of connections._
-Some of such resources may be accessed concurrently but allow only a limited number of connections, others require exclusive access. Adding different locks to shared resources addresses these cases: you can define a resource on the project level, configure its parameters (for example, type and quota), and then use this resource in specific build configurations by adding the Shared Resources build feature to them. The build starts once the lock on the resource is acquired; on the build completion, the lock is released. While the builds using the resource are [running](build-state.md), the resource is unavailable, and the other builds requiring locks will be waiting in the [queue](build-queue.md).
+Some of such resources may be accessed concurrently but allow only a limited number of connections, others require exclusive access. Adding different locks to shared resources addresses these cases: you can define a resource on the project level, configure its parameters (for example, type and quota), and then use this resource in specific build configurations by adding the Shared Resources build feature to them. The build starts once the lock on the resource is acquired; on the build completion, the lock is released. While the builds using the resource are [running](build-state.md), the resource is unavailable, and the other builds requiring locks will be waiting in the [queue](working-with-build-queue.md).
## Adding and Editing Shared Resources
@@ -54,7 +54,7 @@ While read locks enable multiple builds to concurrently access a shared resource
Resources with custom values support three types of locks:
* Locks on __any available value__: a build that uses the resource will start if at least one of the values is available. If all values are being used at the moment, the build will wait in the queue.
* Locks on __all__ values: a build will lock all the values of the resource. No other builds that use this resource will start until the current one is finished.
-* Locks on a __specific__ value: only a specific value of the resource will be passed to the build. If the value is already taken by a running build, the new build will wait in the [queue](build-queue.md) until the value becomes available.
+* Locks on a __specific__ value: only a specific value of the resource will be passed to the build. If the value is already taken by a running build, the new build will wait in the [queue](working-with-build-queue.md) until the value becomes available.
diff --git a/topics/starteam.md b/topics/starteam.md
index da42bd10d..3153eb40a 100644
--- a/topics/starteam.md
+++ b/topics/starteam.md
@@ -1,7 +1,7 @@
[//]: # (title: StarTeam)
[//]: # (auxiliary-id: StarTeam)
-This page describes the fields and options available when setting up VCS roots using StarTeam.
+This article describes the fields and options available when setting up VCS roots using StarTeam.
Common VCS root properties are described [here](configuring-vcs-roots.md#Common+VCS+Root+Properties).
diff --git a/topics/statistic-charts.md b/topics/statistic-charts.md
index 475c34268..df52007a2 100644
--- a/topics/statistic-charts.md
+++ b/topics/statistic-charts.md
@@ -83,7 +83,7 @@ This chart displays red and yellow dots to track the number of discovered errors
## Tests Statistics
-You can also find some useful statistics for a particular test: __Test duration__ graph on the __Test History__ page, which allows comparing the amount of time it takes individual tests to run on the builds of this build configuration. For more details refer to the [related page](working-with-build-results.md#Test+Duration+Graph).
+You can also find some useful statistics for a particular test: __Test duration__ graph on the __Test History__ page, which allows comparing the amount of time it takes individual tests to run on the builds of this build configuration. For more details refer to the [related page](build-results-page.md#Test+Duration+Graph).
## Custom Charts
@@ -91,7 +91,7 @@ It is possible to [customize project-level charts](customizing-statistics-charts
- Build Configuration
+ Build Configuration
Build State
Change
diff --git a/topics/storing-project-settings-in-version-control.md b/topics/storing-project-settings-in-version-control.md
index caff8e783..7953920eb 100644
--- a/topics/storing-project-settings-in-version-control.md
+++ b/topics/storing-project-settings-in-version-control.md
@@ -31,7 +31,7 @@ The default mode is a _two-way synchronization_, that is when the _Allow editing
If you disable the _Allow editing project settings via UI_ option, the project settings will become read-only in the UI and will only reflect changes made in the VCS. This is convenient if you prefer defining project settings' [as code](kotlin-dsl.md) or load settings from a read-only VCS branch.
-Enabling synchronization for a project also enables it for all its subprojects with the default "_Use settings from a parent project_" option selected. TeamCity synchronizes all changes to the project settings (including modifications of [build configurations](build-configuration.md), [templates](build-configuration-template.md), [VCS roots](vcs-root.md), and so on) except [SSH keys](ssh-keys-management.md).
+Enabling synchronization for a project also enables it for all its subprojects with the default "_Use settings from a parent project_" option selected. TeamCity synchronizes all changes to the project settings (including modifications of [build configurations](managing-builds.md), [templates](build-configuration-template.md), [VCS roots](vcs-root.md), and so on) except [SSH keys](ssh-keys-management.md).
However, if for certain subprojects the "_Synchronization disabled_" option is selected, such subprojects will not be synchronized even if this option is enabled for their parent project.
As soon as synchronization is enabled in a project, TeamCity will make an initial commit in the selected repository for the whole project tree (the project with all its subprojects) to store the current settings from the server. If the settings for the given project are found in the specified VCS root (the VCS root for the parent project settings or the user-selected VCS root), a warning will be displayed asking if TeamCity should
@@ -59,8 +59,8 @@ This gives multiple options:
To define which settings to take __when a build starts__, open the __Project Settings | Versioned Settings__ page, click __Show advanced options__, and select one of the following options:
* __always use current settings__: all builds use current project settings from the TeamCity server. Settings' changes in branches, history, and personal builds are ignored. Users cannot run a build with custom project settings.
-* __use current settings by default__: a build uses the latest project settings from the TeamCity server. Users can run a build with older project settings via the [custom build dialog](running-custom-build.md#Changes).
-* __use settings from VCS__: builds in branches and history builds, which use settings from VCS, load settings from the versioned settings' revision calculated for the build. Users can change configuration settings in [personal builds from IDE](remote-run.md) or can run a build with project settings current on the TeamCity server via the [custom build dialog](running-custom-build.md#Changes).
+* __use current settings by default__: a build uses the latest project settings from the TeamCity server. Users can run a build with older project settings via the [custom build dialog](build-results-page.md#Changes+Tab).
+* __use settings from VCS__: builds in branches and history builds, which use settings from VCS, load settings from the versioned settings' revision calculated for the build. Users can change configuration settings in [personal builds from IDE](remote-run.md) or can run a build with project settings current on the TeamCity server via the [custom build dialog](build-results-page.md#Changes+Tab).
TeamCity will try to use settings from the current build's branch whenever possible. However, some of the build features and settings might require using the default configuration (the one stored in TeamCity Data Directory). In general,
* changes in the following settings coming from the build's branch will be ignored and __will not affect__ the build:
* VCS roots and checkout rules
diff --git a/topics/subversion.md b/topics/subversion.md
index fbfe08396..49b98014b 100644
--- a/topics/subversion.md
+++ b/topics/subversion.md
@@ -1,7 +1,7 @@
[//]: # (title: Subversion)
[//]: # (auxiliary-id: Subversion)
-This page contains descriptions of Subversion-specific fields and options available when setting up a VCS root.
+This article contains descriptions of Subversion-specific fields and options available when setting up a VCS root.
Common VCS root properties are described [here](configuring-vcs-roots.md#Common+VCS+Root+Properties).
@@ -95,8 +95,8 @@ Externals support
Select one of the following options to control the SVN externals processing.
-* _Full support (load changes and checkout)_: TeamCity will check out all configuration's sources (including the sources from the externals) and will gather and display information about externals' changes on the __[Changes](viewing-your-changes.md)__ tab.
-* _Checkout, but ignore changes_: TeamCity will check out the sources from externals but any changes in externals' source files will not be gathered and displayed on the __[Changes](viewing-your-changes.md)__ tab. You can use this option if you have several SVN externals and do not want to get information about any changes made in the externals' source files.
+* _Full support (load changes and checkout)_: TeamCity will check out all configuration's sources (including the sources from the externals) and will gather and display information about externals' changes on the __[Changes](viewing-user-changes-in-builds.md)__ tab.
+* _Checkout, but ignore changes_: TeamCity will check out the sources from externals but any changes in externals' source files will not be gathered and displayed on the __[Changes](viewing-user-changes-in-builds.md)__ tab. You can use this option if you have several SVN externals and do not want to get information about any changes made in the externals' source files.
diff --git a/topics/system-requirements.md b/topics/system-requirements.md
index 2c2faa1d3..915844f16 100644
--- a/topics/system-requirements.md
+++ b/topics/system-requirements.md
@@ -224,9 +224,9 @@ If you consider cloud deployment for TeamCity agents (for example, on Amazon EC2
The network traffic mostly depends on your settings as some of them imply transferring binaries between the agent and the server.
The most important flows of traffic between a TeamCity agent and the TeamCity server are:
-* The agent retrieves commands from the server: these are typically build start tasks, including a dump of the build configuration settings and the full set of build parameters. These parameters can be reviewed on the build's [Parameters](working-with-build-results.md#Parameters) tab.
+* The agent retrieves commands from the server: these are typically build start tasks, including a dump of the build configuration settings and the full set of build parameters. These parameters can be reviewed on the build's [Parameters](build-results-page.md#Parameters+Tab) tab.
* The agent periodically sends current status data to the server (this includes all the agents’ parameters which can be reviewed on the agent's [Agent Parameters](viewing-build-agent-details.md#Agent+Parameters) tab).
-* During the build, the agent sends build log messages and parameters data back to the server. These can be reviewed on the [Build Log](working-with-build-results.md#Build+Log) and [Parameters](working-with-build-results.md#Parameters) tabs of the build.
+* During the build, the agent sends build log messages and parameters data back to the server. These can be reviewed on the [Build Log](build-results-page.md#Build+Log+Tab) and [Parameters](build-results-page.md#Parameters+Tab) tabs of the build.
* (when the server-side checkout mode is used) The agent downloads the sources before the build (as a full or incremental patch) from the server.
* (when an [artifact dependency](artifact-dependencies.md) is configured) The agent downloads build artifacts of other builds from the server before starting a build, unless an external artifact storage is used instead.
* (when artifacts are configured for a build) The agent uploads build artifacts to the server, unless an external artifact storage is used instead.
diff --git a/topics/teamcity-cloud-cost-optimization.md b/topics/teamcity-cloud-cost-optimization.md
index d6cce33ea..24d560508 100644
--- a/topics/teamcity-cloud-cost-optimization.md
+++ b/topics/teamcity-cloud-cost-optimization.md
@@ -35,7 +35,7 @@ You can make TeamCity aware of the extra VCS usernames by populating the [additi
-This measure not only ensures you use the minimum number of committer slots, but also allows users to correctly track their changes on the __[Changes](viewing-your-changes.md)__ tab and see all of their personal builds on the **Projects** page.
+This measure not only ensures you use the minimum number of committer slots, but also allows users to correctly track their changes on the __[Changes](viewing-user-changes-in-builds.md)__ tab and see all of their personal builds on the **Projects** page.
## Use Performance Monitor to show statistics and spot bottlenecks
@@ -78,7 +78,7 @@ In this example, a quiet period of 300 seconds (5 minutes) has been defined for
One important note regarding the use of quiet period: if you have selected the option to trigger a build on each check-in, the quiet period settings will be ignored.
-When multiple commits are combined in one build, you are still able to see the full list of the changes in the build by going to its **[Changes](working-with-build-results.md#Changes)** tab, even if the commits were made by several developers. In addition, if a build fails, you can cross-reference the error or failure with the list of changes to see who might have contributed to the failure.
+When multiple commits are combined in one build, you are still able to see the full list of the changes in the build by going to its **[Changes](build-results-page.md#Changes+Tab)** tab, even if the commits were made by several developers. In addition, if a build fails, you can cross-reference the error or failure with the list of changes to see who might have contributed to the failure.
>The [Investigations Auto Assigner](investigations-auto-assigner.md) build feature can automatically suggest assigning a failure to a particular committer based on a number of built-in heuristics.
diff --git a/topics/teamcity-cloud-documentation.md b/topics/teamcity-cloud-documentation.md
index a7f16d6d5..de85d8301 100644
--- a/topics/teamcity-cloud-documentation.md
+++ b/topics/teamcity-cloud-documentation.md
@@ -25,7 +25,7 @@ Welcome to the documentation for [TeamCity Cloud](https://www.jetbrains.com/team
* [Manage Cloud Subscription and Resources](managing-subscription-and-resources.md)
* [Configure Global Settings](teamcity-configuration-and-maintenance.md)
-* [Work with Projects and Build Configurations](managing-projects-and-build-configurations.md)
+* Work with [Projects](creating-and-editing-projects.md) and [Build Configurations](creating-and-editing-build-configurations.md)
* [Manage Users and their Permissions](managing-users-and-roles.md)
|
diff --git a/topics/teamcity-cloud-documentation.xml b/topics/teamcity-cloud-documentation.xml
index 2a8deafe6..b893da8b2 100644
--- a/topics/teamcity-cloud-documentation.xml
+++ b/topics/teamcity-cloud-documentation.xml
@@ -36,7 +36,7 @@
Administer TeamCity
Manage Cloud subscription and resources
- Work with Projects and Build Configurations
+ Work with Projects and Build Configurations
Manage users and permissions
diff --git a/topics/teamcity-cloud-subscription-and-licensing.md b/topics/teamcity-cloud-subscription-and-licensing.md
index 195634e0b..3b96678f6 100644
--- a/topics/teamcity-cloud-subscription-and-licensing.md
+++ b/topics/teamcity-cloud-subscription-and-licensing.md
@@ -155,7 +155,7 @@ __JetBrains-hosted build agent__
-A [build agent](build-agent.md) that can be used out of the box, without any additional configuration. Such build agents are configured, maintained, and hosted by [JetBrains](https://www.jetbrains.com/). When a build is added to the [queue](build-queue.md), a new JetBrains-hosted agent, matching the [build requirements](agent-requirements.md), automatically launches and starts your build.
+A [build agent](build-agent.md) that can be used out of the box, without any additional configuration. Such build agents are configured, maintained, and hosted by [JetBrains](https://www.jetbrains.com/). When a build is added to the [queue](working-with-build-queue.md), a new JetBrains-hosted agent, matching the [build requirements](agent-requirements.md), automatically launches and starts your build.
JetBrains-hosted build agents come with a preinstalled set of commonly used build software. You can view a complete list [here](supported-platforms-and-environments.md#TeamCity+Agent). Additionally, TeamCity can run certain [build steps](configuring-build-steps.md) within a [Docker container](docker-wrapper.md). This allows executing steps that require software that may not be on the build agents by default.
diff --git a/topics/teamcity-data-clean-up.md b/topics/teamcity-data-clean-up.md
index efbd00f43..322f6a136 100644
--- a/topics/teamcity-data-clean-up.md
+++ b/topics/teamcity-data-clean-up.md
@@ -162,7 +162,7 @@ To change the timeout, set the `teamcity.deletedEntities.cleanupTimeout` [intern
{product="tc"}
There are builds that preserve all their data and are not affected during clean-up. These are:
-* [pinned builds](pinned-build.md)
+* [pinned builds](build-actions.md#Pin+Build)
* builds used as an [artifact of snapshot dependency](configuring-dependencies.md) in other builds when the "_[Prevent clean-up](#Base+Rule+Behavior+for+Dependency+Builds)_" option for dependencies is enabled in the build configuration. Such builds are marked with the  icon in the build history list
* builds of build configurations that were deleted less than one day ago
diff --git a/topics/teamcity-data-directory.md b/topics/teamcity-data-directory.md
index c5c9903aa..6e56b1201 100644
--- a/topics/teamcity-data-directory.md
+++ b/topics/teamcity-data-directory.md
@@ -101,7 +101,7 @@ The `config` subdirectory of TeamCity Data Directory contains the configuration
* __`.BuildServer/system`__ — a directory where build results data is stored. The content of the directory is generated by TeamCity and is not meant for manual editing.
- * `artifacts` — the [default directory](teamcity-configuration-and-maintenance.md) where the builds' artifacts, logs and other data are stored. The format of the artifact storage is `//` (read more about the [internal build ID](working-with-build-results.md#Internal+Build+ID)). If necessary, the files in each build's directory can be added/removed manually — this will be reflected in the corresponding build's artifacts.
+ * `artifacts` — the [default directory](teamcity-configuration-and-maintenance.md) where the builds' artifacts, logs and other data are stored. The format of the artifact storage is `//` (read more about the [internal build ID](build-results-page.md#Internal+Build+ID)). If necessary, the files in each build's directory can be added/removed manually — this will be reflected in the corresponding build's artifacts.
* `.teamcity` subdirectory stores build's [hidden artifacts](build-artifact.md#Hidden+Artifacts) and build logs (see below). The files can be deleted manually, if necessary, but it is not recommended as the build will lose the corresponding features backed by the files (like the build log, displaying/using finished build parameters including for the build reuse as snapshot dependency, coverage reports, and so on)
* `logs` subdirectory stores the [build log](build-log.md) in an internal format. The build log stores the build output, compilation errors, test output, and test failure details. The files can be removed manually, if necessary, but corresponding builds will lose build log and failure details (as well as test failure details).
diff --git a/topics/teamcity-documentation.md b/topics/teamcity-documentation.md
index 35e291f5d..48be4c6d0 100644
--- a/topics/teamcity-documentation.md
+++ b/topics/teamcity-documentation.md
@@ -32,7 +32,7 @@ Welcome to the documentation for [TeamCity 2021.x](https://www.jetbrains.com/tea
### Administer
* [Configure and Maintain TeamCity Server](teamcity-configuration-and-maintenance.md)
-* [Work with Projects and Build Configurations](managing-projects-and-build-configurations.md)
+* Work with [Projects](creating-and-editing-projects.md) and [Build Configurations](creating-and-editing-build-configurations.md)
* [Manage Users and their Permissions](managing-users-and-roles.md)
* [Upgrade](upgrading-teamcity-server-and-agents.md)
diff --git a/topics/teamcity-documentation.xml b/topics/teamcity-documentation.xml
index 397c5c4ee..93948061b 100644
--- a/topics/teamcity-documentation.xml
+++ b/topics/teamcity-documentation.xml
@@ -36,7 +36,7 @@
Administer TeamCity
Configure and maintain TeamCity Server
- Work with Projects and Build Configurations
+ Work with Projects and Build Configurations
Manage users and permissions
diff --git a/topics/teamcity-memory-monitor.md b/topics/teamcity-memory-monitor.md
index 66c81efe0..90ce8d6b5 100644
--- a/topics/teamcity-memory-monitor.md
+++ b/topics/teamcity-memory-monitor.md
@@ -5,15 +5,15 @@ TeamCity server checks available memory on a regular basis and warns you if the
There are several warning types reported:
-### Low pool memory
+## Low pool memory
Is reported when memory usage in a single memory pool exceeds 90% after garbage collection. High server activity may cause such memory usage.
-### Low total memory
+## Low total memory
Is reported when more than 90% of total memory has been in use during the last 5 minutes and more than 20% of CPU resources are being consumed by garbage collection. Lasting memory lack may result in performance degradation and server instability as well.
-### Heavy GC overload
+## Heavy GC overload
Is reported when memory cleaning takes more than 50% of CPU resources on average. It usually means really serious problems with memory resulting in high performance degradation.
diff --git a/topics/teamcity-monitoring-and-diagnostics.md b/topics/teamcity-monitoring-and-diagnostics.md
index 139a5bea0..b19a6e5e1 100644
--- a/topics/teamcity-monitoring-and-diagnostics.md
+++ b/topics/teamcity-monitoring-and-diagnostics.md
@@ -1,9 +1,9 @@
[//]: # (title: TeamCity Monitoring and Diagnostics)
[//]: # (auxiliary-id: TeamCity Monitoring and Diagnostics)
-TeamCity provides a variety of diagnostic tools and indicators to monitor and troubleshoot the server, which are accessible from the __Administration | Diagnostics__ page.
+TeamCity provides a variety of diagnostic tools and indicators to monitor and troubleshoot the server. These tools make it easier to identify and investigate problems and, if needed, [report issues](reporting-issues.md) on your server.
-The tools make it easier to identify and investigate problems and, if needed, [report issues](reporting-issues.md) on your server.
+This article describes the diagnostics tools available in __Administration | Diagnostics__. You can also find more details in the nested articles of this section.
## Troubleshooting
diff --git a/topics/user-s-guide.md b/topics/user-s-guide.md
index 5cae40172..b477aef22 100644
--- a/topics/user-s-guide.md
+++ b/topics/user-s-guide.md
@@ -5,7 +5,7 @@ This guide is intended for anyone using TeamCity. Explore TeamCity and learn how
* [Manage your User Account](configuring-your-user-profile.md)
* [Subscribe to Notifications](adding-notification-rules.md)
-* [View Your Changes](viewing-your-changes.md)
+* [View Your Changes](viewing-user-changes-in-builds.md)
* [View Tests and Configuration Problems](viewing-tests-and-configuration-problems.md)
* [Work with Build Results](working-with-build-results.md)
* [Investigate and Mute Build Problems](investigating-and-muting-build-failures.md)
diff --git a/topics/using-build-parameters.md b/topics/using-build-parameters.md
index f2a68d7ac..25282752e 100644
--- a/topics/using-build-parameters.md
+++ b/topics/using-build-parameters.md
@@ -18,7 +18,7 @@ For details on reusing or overriding parameters within a build chain, refer to [
## Using Build Parameters in VCS Labeling Pattern and Build Number
-In the [build number](build-number.md) pattern or [VCS labeling](vcs-labeling.md) pattern, you can use the `%.parameter_name%` syntax to reference any parameter known by TeamCity:
+In the build number pattern or [VCS labeling](vcs-labeling.md) pattern, you can use the `%.parameter_name%` syntax to reference any parameter known by TeamCity:
* Predefined parameters of a [server](predefined-build-parameters.md#Predefined+Server+Build+Parameters) or [build configuration](predefined-build-parameters.md#Predefined+Configuration+Parameters).
* Custom build parameters added on the __Build Configuration Settings | Parameters__ page.
diff --git a/topics/using-teamcity-as-nuget-feed.md b/topics/using-teamcity-as-nuget-feed.md
index e65a53993..3dde02cb7 100644
--- a/topics/using-teamcity-as-nuget-feed.md
+++ b/topics/using-teamcity-as-nuget-feed.md
@@ -122,7 +122,7 @@ You can add TeamCity NuGet feeds as package sources on your developer machine. F
You can use TeamCity NuGet feeds to restore packages in your builds via the [NuGet Installer](nuget-installer.md) and [NuGet Publish](nuget-publish.md) build runners, or the [.NET](net.md) runner with the MSBuild `restore` target. Obsolete [MSBuild](msbuild.md) and [Visual Studio (sln)](visual-studio-sln.md) runners are also supported.
TeamCity uses own [credential provider](https://docs.microsoft.com/en-us/nuget/reference/extensibility/nuget-exe-credential-providers) to automatically authenticate requests to the private TeamCity NuGet feeds.
->The packages available in the feed are bound to the builds' artifacts: they are removed from the feed when the artifacts of the build which produced them are [cleaned up](teamcity-data-clean-up.md). To avoid clean-up of artifacts in a specific build, [pin this build](pinned-build.md).
+>The packages available in the feed are bound to the builds' artifacts: they are removed from the feed when the artifacts of the build which produced them are [cleaned up](teamcity-data-clean-up.md). To avoid clean-up of artifacts in a specific build, [pin this build](build-actions.md#Pin+Build).
Internet Explorer settings may need to be set to trust the TeamCity server when working in a mixed authentication environment.
diff --git a/topics/vcs-labeling.md b/topics/vcs-labeling.md
index 3fbfb60db..ecdc2ffcf 100644
--- a/topics/vcs-labeling.md
+++ b/topics/vcs-labeling.md
@@ -1,7 +1,7 @@
[//]: # (title: VCS Labeling)
[//]: # (auxiliary-id: VCS Labeling)
-TeamCity can label (tag) sources of a particular build (automatically or manually) in your Version Control System. The list of applied labels and their application status is displayed on the __[Changes](working-with-build-results.md#Changes)__ tab of __Build Results__.
+TeamCity can label (tag) sources of a particular build (automatically or manually) in your Version Control System. The list of applied labels and their application status is displayed on the __[Changes](build-results-page.md#Changes+Tab)__ tab of __Build Results__.
## Automatic VCS labeling
diff --git a/topics/vcs-root.md b/topics/vcs-root.md
index 7428c3e50..321f29e8e 100644
--- a/topics/vcs-root.md
+++ b/topics/vcs-root.md
@@ -19,7 +19,7 @@ On an attempt to create a new VCS root, TeamCity checks whether there are other
-Once a VCS root is configured, TeamCity regularly queries the version control system for new changes and displays the changes in the [build configurations](build-configuration.md) that have the root attached. You can set up your build configuration to trigger a new build each time TeamCity detects changes in any of the build configuration's VCS roots, which suits most cases. When a build starts, TeamCity gets the changed files from the version control and applies the changes to the [Build Checkout Directory](build-checkout-directory.md).
+Once a VCS root is configured, TeamCity regularly queries the version control system for new changes and displays the changes in the [build configurations](managing-builds.md) that have the root attached. You can set up your build configuration to trigger a new build each time TeamCity detects changes in any of the build configuration's VCS roots, which suits most cases. When a build starts, TeamCity gets the changed files from the version control and applies the changes to the [Build Checkout Directory](build-checkout-directory.md).
@@ -27,7 +27,7 @@ Once a VCS root is configured, TeamCity regularly queries the version control sy
Project
- Build Configuration
+ Build Configuration
Build Configuration Template
diff --git a/topics/viewing-build-agent-details.md b/topics/viewing-build-agent-details.md
index dff820da0..a4eaf2495 100644
--- a/topics/viewing-build-agent-details.md
+++ b/topics/viewing-build-agent-details.md
@@ -74,6 +74,5 @@ The tab lists system properties, environment variables, and configuration parame
Build Agent
- Run Configuration Policy
\ No newline at end of file
diff --git a/topics/viewing-build-configuration-details.md b/topics/viewing-build-configuration-details.md
deleted file mode 100644
index 3248f0bea..000000000
--- a/topics/viewing-build-configuration-details.md
+++ /dev/null
@@ -1,53 +0,0 @@
-[//]: # (title: Viewing Build Configuration Details)
-[//]: # (auxiliary-id: Viewing Build Configuration Details)
-
-The __Build Configuration Home__ page provides the configuration details and enables you to:
-
-* [run a custom build](running-custom-build.md) using the __Run__ button
-* using the __Actions__ menu
- * [pause triggers](build-configuration.md#Build+Configuration+State)
- * check for [pending changes](change-state.md)
- * enforce [clean checkout](clean-checkout.md)
- * [assign an investigation](investigating-and-muting-build-failures.md)
- * [clean stream workspaces on a Perforce server](perforce-workspace-handling-in-teamcity.md#Cleaning+Workspaces+on+Perforce+Server)
-* [edit the configuration settings](creating-and-editing-build-configurations.md#Configuring+Settings)
-
-The build configuration details are separated into several tabs whose number may vary depending on your server or project configuration, for example, [dependencies](dependent-build.md), [TeamCity integration with other tools](integrating-teamcity-with-other-tools.md), and so on.
-
-## Overview
-
-Provides information on:
-
-* __Pending Changes__ also listed as a separate tab, see the details [below](#Pending+Changes)
-* __Current Status__ of the build configuration, and, if applicable:
- * number of [queued builds](build-queue.md)
- * for a running build — the progress details with the __Stop__ option to terminate the build
- * for a [failed build](build-state.md) — the number and [agent](build-agent.md), and so on
-* the [Build History](build-history.md) section lists builds of the current build configuration
-
-## History
-
-Displays [Build History](build-history.md) on a separate page and allows filtering builds by build agents, [tagging builds](build-tag.md) and filtering them by tags (if available).
-
-## Change Log
-
-By default, lists changes from builds finished during the last 14 active days. Use the show all link to view the complete change log.
-
-The page shows the change log with its graph of commits to the [monitored branches](working-with-feature-branches.md#Changes) of all VCS repositories used by the current build configurations and the repositories used by the [dependencies and dependent configurations](dependent-build.md) of the current configuration.
-
-## Statistics
-
-Displays the collected statistical data as [visual charts](statistic-charts.md#Build+Configuration+Statistics).
-
-## Compatible Agents
-
-Lists all authorized agents. Agents meeting [Agent Requirements](agent-requirements.md) are listed as compatible. For each incompatible agent, the reason is provided.
-The agents belonging to the [pool(s)](configuring-agent-pools.md) associated with the current project are listed first.
-
-## Pending Changes
-
-Lists [changes](change-state.md) waiting to be included in the next build on a separate page.
-
-## Settings
-
-Lists the current [build configuration settings](creating-and-editing-build-configurations.md#Configuring+Settings) on a separate page.
\ No newline at end of file
diff --git a/topics/viewing-tests-and-configuration-problems.md b/topics/viewing-tests-and-configuration-problems.md
index e0107844d..5d1c2031b 100644
--- a/topics/viewing-tests-and-configuration-problems.md
+++ b/topics/viewing-tests-and-configuration-problems.md
@@ -1,5 +1,5 @@
[//]: # (title: Viewing Tests and Configuration Problems)
-[//]: # (auxiliary-id: Viewing Tests and Configuration Problems)
+[//]: # (auxiliary-id: Viewing Tests and Configuration Problems;Already Fixed In;First Failure)
## Viewing Problems on Project Overview Page
@@ -81,6 +81,27 @@ As with any failed test, you can assign investigations for a flaky test (or mult
Note that if [branches](working-with-feature-branches.md#Configuring+Branches) are configured for a VCS Root, flaky tests are detected for the default branch only.
+## See Where Test is Already Fixed In
+
+For some [test failures](viewing-tests-and-configuration-problems.md), TeamCity can show the "_Already Fixed In_" build. This is the build where this initially failed test was successful and which was run _after_ the build with initial test failure (for the same build configuration).
+
+Here, _after_ means that:
+* The build with the successful test has newer changes than the build with initial failure.
+* If the changes were the same, the newer build was run after the failed one.
+
+If you run a [history build](history-build.md), TeamCity will not consider it as a candidate for "_Already Fixed In_" for test failures in later builds (in terms of changes).
+
+Tests are considered the same when they have the same name. If there are several tests with the same name within the build, TeamCity counts order number of the test with the same name and considers it as well.
+
+Note that all invocations of the same test within a single build are counted as 1.
+
+## See Where Test First Failed
+
+TeamCity displays the "_First Failure_" build for some tests. This is the build where TeamCity detected the first failure of this test for the same [build configuration](managing-builds.md), which means that starting from the current build, TeamCity goes back throughout the build history to find out when this test failed for the first time. Builds without this test are skipped, and if a successful test run was found, the search stops.
+Here, _back throughout the history_ means that builds are analyzed with regard to changes as detected by TeamCity; as a result, [history builds](history-build.md) will be processed correctly.
+
+A test which runs several times within a single build is counted as one test (that is all invocations of the same test are counted as one).
+
Testing Frameworks
diff --git a/topics/viewing-user-changes-in-builds.md b/topics/viewing-user-changes-in-builds.md
new file mode 100644
index 000000000..ad86efbe6
--- /dev/null
+++ b/topics/viewing-user-changes-in-builds.md
@@ -0,0 +1,32 @@
+[//]: # (title: Viewing User Changes in Builds)
+[//]: # (auxiliary-id: Viewing User Changes in Builds;Viewing Your Changes)
+
+Monitoring the quality of the codebase is essential for a development team: a project developer needs to see whether their commit brought a build failure or not. For a project leader, it is important to detect the code at fault for a build failure to be able to have the situation rectified early, so other members of the team are not inconvenienced.
+
+The __Changes__ page of the TeamCity UI allows you to review the commits made by all TeamCity users and see how they have affected builds. You can filter the results with the user selector on the page.
+
+Changes made by a user are displayed correctly only when appropriate [VCS usernames](creating-and-managing-users.md#VCS+Usernames) are defined.
+
+By default, the page does not show the commits to the build configurations hidden by the current user on the **Projects** page. To remove this filter and view all build configurations, clear the _Hide configurations excluded from my projects_ box.
+
+Each change has a new pie-chart icon with slices showing the relative size of pending, successful, as well as old and new problematic builds affected by the change. Hovering over / clicking the pie-chart icon gives a visual representation of how the user commit has affected different builds. Builds with new/critical problems are listed by default. Expanding the change or clicking the _See builds_ link lists all builds with the change.
+
+From this page you can:
+* View all commits and changes included into personal builds.
+* View how changes have affected the builds.
+* See whether there are new failed tests caused by changes.
+* Navigate to the issue tracker, if the [issue tracker integration is configured](integrating-teamcity-with-issue-tracker.md).
+* Open possibly problematic files in your IDE: the option is available if the plugin for this [IDE is installed](installing-tools.md) and you are logged in to TeamCity from within this IDE.
+* Navigate to change details.
+* Modify the change comment in TeamCity (available to project administrators by default). Changing the comment in the VCS as well is recommended for consistency.
+* View detailed data for each change on the dedicated tabs. To switch between tabs for the currently selected change, use `Tab/Shift+Tab` or mnemonics: `T` for tests, `B` for builds, `F` for files.
+* View builds with any of the changes. By default, successful and pending build configurations are hidden from display. Uncheck the corresponding box to view all builds with the change.
+
+Note that problems which have an investigator/responsible are not considered critical (unless you are the investigator).
+
+
+
+ Build State
+ Change
+
+
diff --git a/topics/viewing-your-changes.md b/topics/viewing-your-changes.md
deleted file mode 100644
index c07e6f0bc..000000000
--- a/topics/viewing-your-changes.md
+++ /dev/null
@@ -1,35 +0,0 @@
-[//]: # (title: Viewing Your Changes)
-[//]: # (auxiliary-id: Viewing Your Changes)
-
-Monitoring the quality of the codebase is essential for a development team: a project developer needs to see whether his/her commit brought a build failure or not; for a project leader it is important to detect the code at fault for a build failure to be able to have the situation rectified early, so other members of the team are not inconvenienced.
-
-The __Changes__ page of the TeamCity web UI allows you to review the commits made by all TeamCity users and see how they have affected builds. You can filter the results with the user selector on the page.
-
-
-
-Changes made by a user are displayed correctly only when appropriate [VCS usernames](creating-and-managing-users.md#VCS+Usernames) are defined.
-
-
-By default, the page does not show the commits to the build configurations hidden by the current user on the Projects dashboard. To remove this filter and view all build configurations, deselect the __Hide configurations excluded from my Projects__ box.
-
-Each change now has a new pie-chart icon with pie slices showing the relative size of pending, successful, as well as old and new problematic builds affected by the change. Hovering over/clicking the pie-chart icon gives a visual representation of how the user commit has affected different builds. Builds with new/critical problems are listed by default. Expanding the change or clicking the _See builds_ link lists all builds with the change.
-
-From this page you can:
-* View all commits and changes included into personal builds
-* View how changes have affected the builds
-* See whether there are new failed tests caused by changes
-* Navigate to the issue tracker, if the [issue tracker integration is configured](integrating-teamcity-with-issue-tracker.md)
-* Open possibly problematic files in your IDE: the option is available if the plugin for this [IDE is installed](installing-tools.md) and you are logged in to TeamCity from within this IDE
-* Navigate to change details
-* Modify the change comment in TeamCity (available to project administrators by default). Changing the comment in the VCS as well is recommended for consistency.
-* View detailed data for each change on the dedicated tabs. To switch between tabs for the currently selected change, use `Tab/Shift+Tab` or mnemonics: `T` for tests, `B` for builds, `F` for files.
-* View builds with any of the changes. By default, successful and pending build configurations are hidden from display. Uncheck the corresponding box to view all builds with the change.
-
-Note that problems which have an investigator/responsible are not considered critical (unless you are the investigator).
-
-
-
- Build State
- Change
-
-
diff --git a/topics/working-with-build-queue.md b/topics/working-with-build-queue.md
new file mode 100644
index 000000000..363488914
--- /dev/null
+++ b/topics/working-with-build-queue.md
@@ -0,0 +1,106 @@
+[//]: # (title: Working with Build Queue)
+[//]: # (auxiliary-id: Working with Build Queue;Ordering Build Queue;Build Queue)
+
+In TeamCity, _build queue_ is a list of builds that were [triggered](configuring-build-triggers.md), or launched manually, and are waiting to be started. TeamCity distributes them to [compatible](agent-requirements.md) build agents as soon as they become idle. A queued build is assigned to an agent at the moment it is started on the agent; no preassignment is made while the build is waiting in the build queue.
+
+## Queue Page
+
+TeamCity shows the list of builds waiting to be run on the __Queue__ page.
+
+This page displays the following information for each build:
+* The position in the queue, which also serves as a link to the __Build Results__ page.
+* The source branch name (if available).
+* A linkable path in the hierarchy: all parent subprojects and the build configuration.
+* Time to start: the estimated wait duration. Hovering over the estimated time value shows a tooltip with the following information:
+ * Expected start/finish time.
+ * The link to the planned agent.
+ * If the current build is a part of a build chain and the builds it depends on are not finished yet, a corresponding note will be displayed. For some builds, like the builds that have never been run before, TeamCity cannot estimate possible duration, so the respective message will be displayed in the tooltip, for example:
+
+* A brief description of the [event that triggered the build](configuring-build-triggers.md).
+* The number of agents compatible with this build configuration. You can click an agent's name link to open the __[Agents](viewing-build-agent-details.md)__ page, or use the down arrow to quickly view the list of compatible agents in the pop-up menu.
+
+## Build Queue Optimization by TeamCity
+
+By default, TeamCity optimizes the build queue as follows:
+* If a similar build exists in the queue, a new build (on the same change set and with the same custom properties) will not be added.
+* If an automatically triggered build chain has more changes than a build chain that is already queued, the latter will be replaced with the automatically triggered build chain, if such replacement will not delay obtaining the build chain results (based on the [estimated duration](#Queue+Page)).
+* While a build chain is in the queue, TeamCity tries to replace the queued builds with equivalent started builds.
+* Builds that have been staying in a queue for longer than 15 days are canceled automatically (for example, if there are no compatible agents).
+ This default behavior can be manually disabled via the corresponding options in the [VCS](configuring-vcs-triggers.md) and [schedule](configuring-schedule-triggers.md) build triggers.
+
+## Agent Selection for Queued Build
+
+When there are several idle agents that can run a queued build, TeamCity tries to select the fastest one as follows:
+1. If no builds have previously run on agents, the [CPU rank](viewing-build-agent-details.md#Agent+Summary) is used to select an agent.
+2. If builds have previously run on agents, the estimated build duration for the given build configuration is used to select an agent. The estimate is made based on heuristics of the latest builds in the history of the build configuration; for estimating, the execution time of the more recent builds has more weight than that of the earlier builds. [Personal](personal-build.md) and [canceled](build-state.md#Canceled%2FStopped+build) builds are not taken into account, neither are any individual builds whose duration differs significantly from the rest of the builds for this build configuration.
+
+## Ordering Build Queue
+
+You can:
+* Reorder the builds in the queue manually.
+* Remove build configurations or personal builds from the queue.
+* With System Administrator permissions, assign different priorities to build configurations, which will affect their position in the queue.
+
+### Manually Reordering Builds in Queue
+
+To reorder builds in the build queue, you need to drag them to the desired position.
+
+### Removing Builds from Build Queue
+
+To remove build(s) from the queue, check the __Remove__ box next to the selected build and confirm the deletion. If a build to be removed from the queue is a part of a build chain, TeamCity shows the respective message below the comment field. Refer to the [Build Chain](build-chain.md#Stopping%2FRemoving+From+Queue+Builds+from+Build+Chain) article for details.
+
+Additionally, you can:
+* Remove all your personal builds from the queue at once from the __Actions__ menu.
+* Remove several builds of [paused build configurations](changing-build-configuration-status.md#Pausing+Several+Build+Configurations+in+Project) from the queue.
+
+### Moving Builds to Top
+
+To move a build to the top spot in the queue, do one of the following:
+* On the **Queue** page, click the arrow button next to the build sequence number .
+* Click the build number or build status link anywhere in the UI, and, on the **[Build Results](working-with-build-results.md)** page of the queued build, click the __Actions__ menu in the upper right corner. Select the __Move to top__ action.
+
+For a [composite build](composite-build-configuration.md), the whole build chain will be moved to the top of the queue. If a running composite build has dependency builds that have not yet started, click the build number or build status link anywhere in the UI, and, on the **[Build Results](working-with-build-results.md)** page of the running build, click the __Actions__ menu in the upper right corner. Select the __Move queued dependencies to top__ action. All queued dependencies of this build will be moved to the top of the queue.
+
+## Managing Build Priorities
+
+By default, builds are placed in the build queue in the order they are triggered: the most recently triggered build is added to the bottom of the queue. It is possible to change the build's priorities so that builds are inserted into the build queue at a position depending on their defined priority and the wait time of the currently queued builds.
+
+You can control build priorities by creating _Priority Classes_. A priority class is a set of build configurations with a specified priority (the higher the number, the higher the priority; for example, `priority=2` is higher than `priority=1`). The higher priority a configuration has, the higher place it gets when added to the build queue.
+
+To access these settings, click __Priorities__ in the upper right corner on the __Queue__ page. Note that this action is only available to system administrators.
+
+There are two predefined priority classes: _Personal_ and _Default_, both with `priority=0`:
+* All personal builds (launched via [Remote Run](remote-run.md) or [Pre-tested Commit](pre-tested-delayed-commit.md)) are assigned to the _Personal_ priority class once they are added to the build queue. You can change the priority for personal builds.
+* The _Default_ class includes all the builds not associated with any other class. This allows creating a class with priority lower than default and place some builds to the bottom of the queue.
+
+To create a new priority class:
+1. Click __Create new priority class__.
+2. Specify its name, priority (in the range `-100..100`), and additional description. Click __Create__.
+3. Click __Add configurations__ and specify which build configurations should have priority defined in this class.
+
+This setting is taken into account only when a build is added to the queue. To ensure that builds with lower priority always have a chance to run, TeamCity also considers how long each build is staying in the queue. This allows running a long awaiting build with lower priority before the recently added builds with higher priority. For a detailed explanation of this behavior, refer to the [algorithm description](https://confluence.jetbrains.com/display/TW/Build+Queue+Priorities#BuildQueuePriorities-Algorithmdetails).
+
+## Pausing and Resuming Build Queue
+
+The build queue can be paused manually or automatically. In this case, the builds are still going to be added to the queue, but they will not be assigned to agents until the queue is unpaused.
+
+Users with the _Enable/disable agent_ permission (included in the [Agent Manager](managing-roles-and-permissions.md#Per-Project+Authorization+Mode) role by default) can manually pause/resume the build queue (since pausing the queue is equivalent to disabling all agents on the server). This action is available in the upper right corner of the __Queue__ page.
+
+The build queue can be paused automatically [if the TeamCity server runs out of disk space](teamcity-disk-space-watcher.md). The queue will be automatically resumed when sufficient space is available.
+{product="tc"}
+
+When the queue is paused, every page in TeamCity will contain a message with information on the reasons for pausing.
+
+## Limiting Maximum Size of Build Queue
+{product="tc"}
+
+It is possible to limit the maximum number of builds in the queue. By default, the limit is 6000 builds. The default value can be changed by configuring the `teamcity.buildTriggersChecker.queueSizeLimit` [internal property](server-startup-properties.md#TeamCity+Internal+Properties).
+
+When the queue size reaches the limit, TeamCity will pause [automatic build triggering](configuring-build-triggers.md). It will be reenabled once the queue size gets below limit. While triggering is paused, a warning message is displayed to all the users.
+However, even if the queue reached the limit and automatic triggering is paused, it is still possible to add builds to the queue [manually](running-custom-build.md).
+
+
+
+ Build Chain
+
+
\ No newline at end of file
diff --git a/topics/working-with-build-results.md b/topics/working-with-build-results.md
index cfac05eab..c81c8960e 100644
--- a/topics/working-with-build-results.md
+++ b/topics/working-with-build-results.md
@@ -1,306 +1,18 @@
[//]: # (title: Working with Build Results)
-[//]: # (auxiliary-id: Working with Build Results)
+[//]: # (auxiliary-id: Working with Build Results;Viewing Build Configuration Details)
-In TeamCity a build goes through several states:
-* Upon some event the build trigger adds the build to the queue where the build stays waiting for a free agent.
-* The build starts on the agent and performs all configured build steps.
-* The build finishes and becomes a part of the build history of this build configuration.
+TeamCity has two main modes: __Home__ and __Settings__. The __Home__ mode accumulates build results at a project and build configuration levels. If you are using the new TeamCity UI, you can navigate between this hierarchy via the _Projects_ sidebar.
-In TeamCity all information about a particular build, whether it is queued, running or finished, is accumulated on the __Build Results__ page. The page can be accessed by clicking the build number or build status link.
+Each mode has its own level of detail. To see the build statistics for the whole project, go to __Project Home__:
-Besides providing the build information, this page enables you to:
-* [Run a custom build](running-custom-build.md) using the __Run__ button.
-* Use the __Actions__ menu to do the following:
- * Add a build to [favorites](favorite-build.md).
- * Add a comment.
- * [Pin the build](pinned-build.md).
- * [Tag the build](build-tag.md).
- * Change the build status, marking the build as [failed](changing-build-status-manually.md#Marking+build+as+failed) or [successful](changing-build-status-manually.md#Marking+build+as+successful).
- * [Label this build's sources](vcs-labeling.md).
- * Remove the build.
- * Re-run the build: this will restart this build only, omitting other builds in its chain if any, which might be helpful if the build failed due to some infrastructure problems.
-* [Edit the configuration settings](creating-and-editing-build-configurations.md#Creating+Build+Configuration+from+Template).
+
-## Build Details
+To browse the details of a single build configuration, click its name to open its __Build Configuration Home__:
-The __Build Results__ page can be accessed from the __Build Configuration Home__ page and from various places in the TeamCity web UI where a build number or build status appears as a link. Some data is accessible only after the build is finished, some details like [Changes](#Changes), [Build Parameters](#Parameters), and [Dependencies](#Dependencies) are also applicable to the build while it is waiting in the queue.
+
-The build information available on the page is described in sections below.
+Whenever you click a particular build on any __Home__ page, TeamCity will show this build's __Build Results__:
-Depending on the build runners enabled as your build steps, the number of tabs on the page and the information on the __Overview__ tab may vary.
+
-### Build Overview
-
-The __Overview__ tab displays general information about the build, such as the build duration, the agent used, trigger, dependencies, and so on. If a build is queued, the tab displays the position of the build in the queue, the time the build is supposed to start, and so on.
-
-If a build is running, the tab displays the build progress. You can also stop a running build using the corresponding link on the __Overview__ tab or the appropriate option from the __Actions__ drop-down menu.
-
-If another build of this same build configuration is concurrently running, a small window appears on the __Overview__ tab with the following information:
-* The build results of that build linking to the __Build results__ page
-* A changes link with a drop-down list of changes included in that build
-* The build number, time of start, and a link to the agent it is running on.
-
-If a build is probably hanging, the corresponding notification is displayed at the top of the __Overview__ tab. In this case TeamCity provides a link to view the process tree of the running build and the thread dumps of each Java or .NET process in a separate frame. If the process is not Java or .NET, its command line is retrieved. The possibility to view the thread dump is supported for the following platforms:
-* Windows, with JDK 1.3 and higher
-* Windows, with JDK 1.6-1.8, using jstack utility
-* Non-Windows, with JDK 1.5-1.8, using jstack utility
-
-The information on the tab may vary depending on the build runners enabled. If configured, you will see the __Code Coverage Summary__ and a link to the full report or/ and the number of duplicates found in your code and a link opening the __Duplicates__ tab, and so on. Refer to the sections below for details on [Code Coverage](#Code+Coverage+Results) and [Duplicates](#Duplicates) Tabs.
-
-If there were problems in the build, the __Overview__ tab also displays them.
-
-If the build has failed tests, you can view them on the __Overview__ tab of the __Build Results__ page.
-
-#### Tests
-
-Successful or failed tests in this build (if any) are displayed on the __Overview__ tab.
-
-For each failed test, you can view its stacktrace, the diff between the expected and actual values, jump to the test [history](#Test+History), [assign a team member to investigate its failure](investigating-and-muting-build-failures.md), [open the test in your IDE](installing-tools.md) and/or start fixing it right away.
-
-To view all tests related to the build, use the dedicated __Tests__ tab. [Learn more](#All+Tests).
-
-## Changes
-
-From the __Changes__ tab you can:
-* Review all changes included in the build with their corresponding [revisions](revision.md) in version control
- * Review changes included in the build that the current build depends on: if the current build configuration has an artifact dependency, and the artifact downloaded in the current build has changed compared to the one downloaded in the previous build of the current configuration, the __Artifact dependencies changes__ node appears displaying the build which was used to download artifact dependencies from, and the changes which were included in that build.
-* [Label the build sources](vcs-labeling.md)
-* [Configure the VCS settings](configuring-vcs-settings.md) of the build configuration (if you have enough permissions).
-
-For each change on this page you can:
-* Explore the change in details
-* View which dependent build the changes come from or builds with snapshot dependencies with the "Show changes from snapshot dependencies" option enabled. On hovering over the  icon, the number of the dependent build is displayed; clicking the link opens the __Сhanges__ tab of the dependent build.
-* Navigate to the __Change Details__ by clicking a changed file link.
-* [Trigger a custom build](running-custom-build.md) with this change.
-* Download patch.
-* Download patch to your IDE.
-* Review the change in an [external change viewer](external-changes-viewer.md), if configured by the administrator.
-{product="tc"}
-
-The __Changes__ tab provides advanced filtering capabilities for the list of changes. Enabling __Show graph__ displays the changes as a graph of commits to the VCS roots related to this build.
-
-The graph appears on the left of the list and allows you to get the view of the changes with a variable level of detailing. You can:
-* View the VCS roots which were changed in this build, each of the roots being represented as a bar.
-* Navigate to a graph node to display the VCS root revision number.
-* Click a bar to select a single VCS root. The changes not pertaining to this root are grayed out.
-* If there have been merges between the branches of the repository, the graph displays them. To collapse a bar, navigate to its darker area and click it to hide history of merges. The dotted line will indicate that the bar is expandable.
-* If your VCS root has subrepositories (marked S in the list of changes), navigate to a node in the parent to see which commits in subrepositories are referenced by this revision in the parent.
-
-You can select to view the modified files by checking the __Show files__ box. Clicking a filename opens the diff viewer.
-
-## All Tests
-
-To view all the tests for a particular build, open the __Build Results__ page, and navigate to the __Tests__ tab. On this page:
-
-
-
-|
-
-Item
-
- |
-
-
-
-Description
-
- |
-
-|
-
-Download all tests in CSV
-
- |
-
-
-
-Click the link to download a file containing all the build tests results.
-
- |
-
-|
-
-Filtering options
-
- |
-
-
-
-Use this area to filter the test list:
-
-* Select the type of items to view: tests, suites, packages/namespaces or classes.
-* Type in the string (for example, test name from the list) thus providing change of scope for the list.
-* Select a test status.
-
- |
-
-|
-
-Show
-
- |
-
-
-
-Select the number of tests to be shown on a page.
-
- |
-
-|
-
-Status
-
- |
-
-
-
-Shows the status (OK, Ignored, and Failure) of the test. Failed tests are shown as red __Failure__ links, which you can click to view and analyze the test failure details. Click the header above this column to sort the table by status.
-
- |
-
-|
-
-Test
-
-
- |
-
-
-
-Click the name of a class, a namespace/package, or a suite to view only the items included in it. Click the arrow next to the test name to view the test history, open the test in the Build Log, start investigation of the failed test, or open the failed test in an IDE.
-
- |
-
-|
-
-Duration
-
-
- |
-
-
-
-Shows the time it took to complete the test. You can view the Test Duration Graph described below by clicking this icon: .
-
- |
-
-|
-
-Order
-
-
- |
-
-
-
-Shows the sequence in which the tests were run. Click the header above this column to sort by the test order number.
-
- |
-
->Watch our **video tutorial** on how to [use the test report page](https://www.youtube.com/watch?v=LKJjcBJT1k0).
-
-#### Test History
-
-To navigate to the history of a particular test, click the arrow next to the test name and select __Test History__ from the drop-down menu.
-There are several places where tests are listed and from where you can open Test History.
-For example:
-* __Project Home__ page | __Current Problems__ tab
-* __Project Home__ page | __Current Problems__ tab | __Problematic Tests__
-* __Build Results__ page | __Overview__ tab
-* __Build Results__ page | __Tests__ tab
-* __Projects__ | __<build with failed tests>__ | build results drop-down menu
-
-Clicking the __Test history__ link opens the __Test details__ page where you can find following information:
-* The test details section including test success rate and test's run duration data:
-* the Test Duration Graph. For more information, refer to the [Test Duration Graph](#Test+Duration+Graph) description below.
-* Complete test history table containing information about the test status, its duration, and information on the builds this test was run in.
-
-#### Test Duration Graph
-
-The Test Duration graph (see the screenshot above) is useful for comparing the amount of time it takes individual tests to run on the builds of this build configuration.
-
-Test duration results are only available for the builds which are currently in the build history. Once a build has been [cleaned up](teamcity-data-clean-up.md), this data is no longer available.
-
-You can perform the following actions on the Test Duration Graph:
-* Filter out the builds that failed the test by clearing the __Show failed__ option.
-* Calculate the daily average values by selecting the __Average__ option.
-* Click a dot plotted on the graph to jump to the page with the results of the corresponding build.
-* View a build summary in the tooltip of a dot on the graph and navigate to the corresponding __Build Results__ page.
-* Filter information by agents selecting or clearing a particular agent or by clicking __All__ or __None__ links to select or clear all agents.
-
-## Build Log
-
-For each build you can view and download its build log. More information on build logs in TeamCity is available [here](build-log.md).
-
-## Parameters
-
-All system properties and environmental variables which were used by a particular build are listed on the __Parameters__ tab of the __Build Results__ page. [Learn more about build parameters](configuring-build-parameters.md).
-
-The __Reported statistic values__ page shows [statistics values](custom-chart.md#Default+Statistics+Values+Provided+by+TeamCity) reported for the build and displays a statistics chart for each of the values on clicking the _View Trend_ icon .
-
-## Dependencies
-
-If a finished build has artifact and/or snapshot dependencies, the __Dependencies__ tab is displayed on the __Build Results__ page. Here you can explore builds whose artifacts and/or sources were used for creating this build (Downloaded artifacts) as well as the builds which used the artifacts and/or sources of the current build (Delivered artifacts). Additionally, you can view indirect dependencies for the build. That is, for example, if build A depends on build B which depends on builds C and D, then these builds C and D are indirect dependencies for build A.
-
-## Related Issues
-
-If you have [integration with an issue tracker ](integrating-teamcity-with-issue-tracker.md) configured, and if there is at least one issue mentioned in the comments for the included changes or in the comments for the build itself, you will see the list of issues related to the current build in the __Issues__ tab.
-
-
->If you need to view all the issues related to a build configuration and not just to particular build, you can navigate to the __Issues Log__ tab available on the build configuration home page, where you can see all the issues mapped to the comments or filter the list to particular range of builds.
-## Build Artifacts
-
-If the build produced [artifacts](build-artifact.md), they all are displayed on the dedicated __Artifacts__ tab.
-
-## Code Coverage Results
-
-If you have code coverage configured in your build runner, a dedicated tab with the full HTML code coverage report appears on the __Build Results__ page.
-
-By clicking the links in the __Coverage Breakdown__ section, you can drill-down to display statistics for different scopes, for example, Namespace, Assembly, Method, and Source Code.
-
-## Code Inspection Results
-
-If configured, the results of a [Code Inspection](configuring-test-reports-and-code-coverage.md#Code+Inspection+in+TeamCity) build step are shown on the __Code Inspection__ tab. Use the left pane to navigate through the inspection results; the filtered inspections are shown in the right pane.
-* Switch from the __Total__ to __Errors__ option, if you're not interested in warnings.
-* Use the scope filter to limit the view to the specific directories. This makes it easier for developers to manage specific code of interest.
-* Use the inspections tree view under the scope filter to display results by specific inspection.
-* Note that TeamCity displays the source code line number that contains the problem. Click it to jump the code in your IDE.
-
-## Duplicates
-
-If your build configuration has Duplicates build runner as one of the build steps, you will see the __Duplicates__ tab in the __Build Results__.
-
-The tab consists of:
-* A list of duplicates found. The __new only__ option enables you to show only the duplicates that appeared in the latest build.
-* A list of files containing these duplicates. Use the left and right arrow buttons to show selected duplicate in the respective pane in the lower part of the tab.
-* Two panes with the source code of the file fragments that contain duplicates.
-* Scope filter in the upper-left corner lists the specific directories that contain the duplicates. This filtering makes it easier for developers to manage the code of interest.
-
-## Maven Build Info
-
-For each Maven build the TeamCity agent gathers Maven specific build details, which are displayed on the __Maven Build Info__ tab of the __Build results__ after the build is finished.
-
-[//]: # (Internal note. Do not delete. "Working with Build Resultsd371e671.txt")
-
-## Internal Build ID
-
-In the URL of the build result page you can find the parameter `buildId` with a numeric value. This number is internal build id uniquely identifying the build in the TeamCity installation. You might need this ID when constructing URL manually. For example, for [REST API](https://www.jetbrains.com/help/teamcity/rest/teamcity-rest-api-documentation.html), [downloading artifacts](patterns-for-accessing-build-artifacts.md).
-
-
-
- Investigating and Muting Build Failures
- Viewing Tests and Configuration Problems
-
-
- Build Log
- Build Artifact
- Change
-
-
- Configuring Test Reports and Code Coverage
- Creating and Editing Build Configurations
-
-
- Video tutorial: TeamCity for developers
-
-
\ No newline at end of file
+This section contains articles explaining how you can use these modes to browse build results in TeamCity. Refer to the sidebar to see the contents of this section.
\ No newline at end of file
diff --git a/topics/youtrack.md b/topics/youtrack.md
index 6f852c840..0328a61e8 100644
--- a/topics/youtrack.md
+++ b/topics/youtrack.md
@@ -9,11 +9,11 @@ Note that TeamCity does not support the [legacy YouTrack REST API endpoints](htt
When integration with YouTrack is enabled, TeamCity automatically detects YouTrack issue IDs mentioned in the comments of VCS commits. It transforms these IDs into links to the corresponding issues in YouTrack and displays them to TeamCity users in the UI.
-To see the basic details of an issue in the TeamCity UI, open the __[Changes](working-with-build-results.md#Changes)__ tab of the related build’s results and hover over the icon next to the issue ID:
+To see the basic details of an issue in the TeamCity UI, open the __[Changes](build-results-page.md#Changes+Tab)__ tab of the related build’s results and hover over the icon next to the issue ID:
-Issues fixed in the build can be viewed on the __[Issues](working-with-build-results.md#Related+Issues)__ tab of the build results:
+Issues fixed in the build can be viewed on the __[Issues](build-results-page.md#Issues+Tab)__ tab of the build results:
|