Major tree update + user guide refactor

cfg/glossary.xml

@@ -19,5 +19,19 @@
     <term name="vcs-root">
         A set of connection parameters that determine how TeamCity communicates with a VCS to monitor changes and get sources for a build.
     </term>
-
-    </terms>
+    <term name="build-number">
+        A string identifier composed according to the pattern specified in the build configuration settings. It is displayed in the UI and passed into the build as a predefined parameter.
+    </term>
+    <term name="build">
+        A process that performs a certain CI/CD job. Builds consists of steps executing granular operations. A build is executed according to the settings specified in its build configuration.
+    </term>
+    <term name="custom-build-run">
+       A standalone build whose settings have been adjusted compared to its build configuration.
+    </term>
+    <term name="build-chain">
+       A pipeline, or sequence, of builds connected by snapshot dependencies. Usually designed to continuously compile, test, and deliver a certain product or component.
+    </term>
+    <term name="build-configuration">
+       A collection of settings of a certain type of builds that determines their steps, features, and other common parameters. It serves as a blueprint for all builds that belong to it.
+    </term>
+</terms>

redirection-rules.xml

@@ -59,7 +59,7 @@
     <rule id="configuring-test-reports-and-code-coverage">
             <accepts>code-inspection.html</accepts>
             <accepts>code-coverage.html</accepts>
-            <accepts>configuring+unit+testing+and+code+coverage.html</accepts>
+            <accepts>configuring-unit-testing-and-code-coverage.html</accepts>
     </rule>
     <rule id="nunit-support">
         <accepts>teamcity-nunit-test-launcher.html</accepts>
@@ -85,4 +85,27 @@
     <rule id="configuring-agent-pools">
         <accepts>agent-pool.html</accepts>
     </rule>
+    <rule id="working-with-build-results">
+        <accepts>viewing-build-configuration-details.html</accepts>
+    </rule>
+    <rule id="working-with-build-queue">
+        <accepts>build-queue.html</accepts>
+        <accepts>ordering-build-queue.html</accepts>
+    </rule>
+    <rule id="build-actions">
+        <accepts>changing-build-status-manually.html</accepts>
+        <accepts>build-tag.html</accepts>
+        <accepts>pinned-build.html</accepts>
+    </rule>
+    <rule id="viewing-tests-and-configuration-problems">
+        <accepts>already-fixed-in.html</accepts>
+        <accepts>first-failure.html</accepts>
+    </rule>
+    <rule id="build-configuration-home-page">
+        <accepts>maven-related-data.html</accepts>
+    </rule>
+    <rule id="build-results-page">
+        <accepts>build-history.html</accepts>
+    </rule>
+
 </rules>

topics/adding-notification-rules.md

@@ -42,7 +42,7 @@ Make sure your [Version Control username](creating-and-managing-users.md#VCS+Use
 
 </note>
 
-* __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).
 
 </td></tr><tr>
 

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"/>
  <seealso>
         <category ref="concepts">
             <a href="build-agent.md">Build Agent</a>
-            <a href="build-configuration.md">Build Configuration</a>
+            <a href="managing-builds.md">Build Configuration</a>
         </category>
         <category ref="admin-guide">
             <a href="assigning-build-configurations-to-specific-build-agents.md">Assigning Build Configurations to Specific Build Agents</a>

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
 <seealso>
         <category ref="concepts">
             <a href="project.md">Project</a>
-            <a href="build-configuration.md">Build Configuration</a>
+            <a href="managing-builds.md">Build Configuration</a>
         </category>
 </seealso>

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`

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
         <category ref="concepts">
             <a href="build-agent.md">Build Agent</a>
             <a href="agent-requirements.md">Agent Requirements</a>
-            <a href="run-configuration-policy.md">Run Configuration Policy</a>
         </category>
         <category ref="admin-guide">
             <a href="running-custom-build.md">Triggering a Custom Build</a>

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.

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.
 

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: