fix warnings and remove pricing

vijaymatest1 · vijaymatest1 · commit 6a4a3a1c44bb · 2020-07-05T12:48:12.000-04:00
diff --git a/docs/pipelines/process/phases.md b/docs/pipelines/process/phases.md
@@ -807,7 +807,7 @@ YAML is not yet supported in TFS.
 #### [Classic](#tab/classic/)
 When you run a pipeline on a self-hosted agent, by default, none of the sub-directories are cleaned in between two consecutive runs. As a result, you can run incremental builds and deployments, provided that tasks are implemented to do that. However, you can override this behavior using the `Clean build` option under `Get sources` task. The options vary depending on the type of repository that you use.
 
-- [GitHub](../repos/github.md#get-the-source-code)
+- [GitHub](../repos/github.md#checkout)
 - [Azure Repos Git](../repos/azure-repos-git.md)
 - [TFVC](../repos/tfvc.md)
 
diff --git a/docs/pipelines/process/variables.md b/docs/pipelines/process/variables.md
@@ -482,7 +482,7 @@ steps:
 ```
 
 > [!IMPORTANT]
-> By default with GitHub repositories, secret variables associated with your pipeline aren't made available to pull request builds of forks. For more information, see [Validate contributions from forks](../repos/github.md#validate-contributions-from-forks).
+> By default with GitHub repositories, secret variables associated with your pipeline aren't made available to pull request builds of forks. For more information, see [Contributions from forks](../repos/github.md#contributions-from-forks).
 
 ::: moniker-end
 ::: moniker range="< azure-devops-2019"
@@ -496,7 +496,7 @@ Each task that needs to use the secret as an environment variable does remapping
 
 
 > [!IMPORTANT]
-> By default with GitHub repositories, secret variables associated with your pipeline aren't made available to pull request builds of forks. For more information, see [Validate contributions from forks](../repos/github.md#validate-contributions-from-forks).
+> By default with GitHub repositories, secret variables associated with your pipeline aren't made available to pull request builds of forks. For more information, see [Contributions from forks](../repos/github.md#contributions-from-forks).
 
 #### [Azure DevOps CLI](#tab/azure-devops-cli/)
 
diff --git a/docs/pipelines/repos/bitbucket.md b/docs/pipelines/repos/bitbucket.md
@@ -16,7 +16,7 @@ Azure Pipelines can automatically build and validate every pull request and comm
 
 BitBucket and Azure Pipelines are two independent services that integrate well together. Your BitBucket Cloud users do not automatically get access to Azure Pipelines. You must add them explicitly to Azure Pipelines.
 
-## Choose a repository to build
+## Access to BitBucket repositories
 
 # [YAML](#tab/yaml/)
 
@@ -202,16 +202,6 @@ For included branches, a build will be triggered on each push to a pull request
 
 ---
 
-## Pricing
-
-Azure Pipelines is free for BitBucket Cloud repositories, with multiple free offerings available depending on whether your BitBucket repository is public or private.
-
-If your BitBucket repository is open source, you can make your Azure DevOps project **public** so that anyone can view your pipeline's build results, logs, and test results without signing in. When users outside your organization fork your repository and submit pull requests, they can view the status of builds that automatically validate those pull requests. If both your BitBucket repository and your pipeline are public, you can run up to 10 parallel jobs in Azure Pipelines for free. These free jobs have a maximum timeout of 360 minutes (6 hours) each.
-
-If either your BitBucket repository or your pipeline is private, we still provide a free tier. In this tier, you can run one free parallel job that can run up to 60 minutes each time until you've used 1800 minutes per month. When the free tier is no longer sufficient, you can purchase additional Microsoft-hosted parallel jobs.
-
-Learn more about pricing based on [parallel jobs](../licensing/concurrent-jobs.md).
-
 ## FAQ
 
 [!INCLUDE [qa](includes/qa1.md)]
diff --git a/docs/pipelines/repos/github.md b/docs/pipelines/repos/github.md
@@ -514,16 +514,6 @@ GitHub allows three options when one or more Check Runs fail for a PR/commit. Yo
 
 Clicking on the "Re-run" link next to the Check Run name will result in Azure Pipelines retrying the run that generated the Check Run. The resultant run will have the same run number and will use the same version of the source code, configuration, and YAML file as the initial build. Only those jobs that failed in the initial run and any dependent downstream jobs will be run again. Clicking on the "Re-run all failing checks" link will have the same effect. This is the same behavior as clicking "Re-try run" in the Azure Pipelines UI. Clicking on "Re-run all checks" will result in a new run, with a new run number and will pick up changes in the configuration or YAML file.
 
-## Pricing
-
-Azure Pipelines is free for GitHub repositories, with multiple free offerings available depending on whether your GitHub repository and project are public or private.
-
-If your GitHub repository is open source, you can make your Azure DevOps project **public** so that anyone can view your pipeline's build results, logs, and test results without signing in. When users outside your organization fork your repository and submit pull requests, they can view the status of builds that automatically validate those pull requests. If both your GitHub repository and your pipeline are public, you can run up to 10 parallel jobs in Azure Pipelines for free. These free jobs have a maximum timeout of 360 minutes (6 hours) each.
-
-If either your GitHub repository or your pipeline is private, we still provide a free tier. In this tier, you can run one free parallel job that can run up to 60 minutes each time until you've used 1800 minutes per month. When the free tier is no longer sufficient, you can purchase additional Microsoft-hosted parallel jobs.
-
-Learn more about pricing based on [parallel jobs](../licensing/concurrent-jobs.md).
-
 ## FAQ
 
 ### Why isn't a GitHub repository displayed for me to choose in Azure Pipelines?
diff --git a/docs/pipelines/repos/includes/ci-triggers4.md b/docs/pipelines/repos/includes/ci-triggers4.md
@@ -11,10 +11,16 @@ Select **Enable continuous integration** on the **Triggers** tab to enable this
 
 ### Batch changes
 
-Select this check box if you have many team members uploading changes often and you want to reduce the number of builds you are running. If you select this option, when a build is running, the system waits until the build is completed and then queues another build of all changes that have not yet been built.
+Select this check box if you have many team members uploading changes often and you want to reduce the number of builds you are running. If you select this option, when a build is running, the system waits until the run is completed and then queues another run of all changes that have not yet been built.
 
 > You can batch changes and build them together.
 
+> [!NOTE]
+> If you use batching with a multi-stage YAML pipeline, then a run must reach a terminal state before the next one can start. This is often not desirable as a multi-stage pipeline may go through approvals and long-running deployment stages. In these cases, it is recommended that you follow one of these solutions:
+> * do not use batching
+> * split the pipeline into two separate pipelines - one for CI and one CD
+> * set appropriate conditions on stages to skip them and make a run terminate quickly
+
 ### Branch filters
 
 You can specify the branches where you want to trigger builds. If you want to use wildcard characters, then type the branch specification (for example, `features/modules/*`) and then press Enter.
