acrolinx

Author: Steve Danielson

docs/pipelines/repos/includes/limitations-gh.md

@@ -1,2 +1,2 @@
-* For best performance, we recommend a maximum of 50 pipelines in a single repository. For acceptable performance, we recommend a maximum of 100 pipelines in a single repository. The more pipelines there are, the slower the processing of a push to that repository. Whenever there is push to a repository, Azure Pipelines needs to load all YAML pipelines in that repository to figure out if any of them need to run, and each loaded pipeline incurs a performance penalty.
+* For best performance, we recommend a maximum of 50 pipelines in a single repository. For acceptable performance, we recommend a maximum of 100 pipelines in a single repository. The time required to process a push to a repository increases with the number of pipelines in that repository. Whenever there's push to a repository, Azure Pipelines needs to load all YAML pipelines in that repository to figure out if any of them need to run, and each loaded pipeline incurs a performance penalty.
 * Azure Pipelines loads a maximum of 2000 branches from a repository into dropdown lists in the Azure Devops Portal, for example into the **Default branch for manual and scheduled builds** setting, or when choosing a branch when running a pipeline manually. If you don't see your desired branch in the list, type the desired branch name manually.

docs/pipelines/repos/on-premises-bitbucket.md

@@ -20,7 +20,7 @@ If your on-premises server is reachable from the servers that run Azure Pipeline
 
 If your on-premises server is not reachable from the servers that run Azure Pipelines service, then:
 - you can set up classic build pipelines and start manual builds
-- you cannot configure CI triggers
+- you can't configure CI triggers
 
 > [!NOTE] 
 > YAML pipelines do not work with on-premises Bitbucket repositories.
@@ -34,36 +34,36 @@ If your on-premises server is reachable from the hosted agents, then you can use
 
 If your on-premises Bitbucket server is reachable from Azure Pipelines service, create a **[Other Git](../library/service-endpoints.md#other-git-service-connection)** service connection and use that to create a pipeline. Check the option to **Attempt accessing this Git server from Azure Pipelines**.
 
-CI triggers work through polling and not through webhooks. In other words, Azure Pipelines periodically checks the Bitbucket server if there are any updates to code. If there are, then Azure Pipelines will start a new run.
+CI triggers work through polling and not through webhooks. In other words, Azure Pipelines periodically checks the Bitbucket server if there are any updates to code. If there are, then Azure Pipelines starts a new run.
 
 ### Not reachable from Azure Pipelines
 
-If the Bitbucket server cannot be reached from Azure Pipelines, you have two options:
+If the Bitbucket server can't be reached from Azure Pipelines, you have two options:
 
 * Work with your IT department to open a network path between Azure Pipelines and on-premises Git server. For example, you can add exceptions to your firewall rules to allow traffic from Azure Pipelines to flow through. See the section on [Azure DevOps IPs](#azure-devops-ip-addresses) to see which IP addresses you need to allow. Furthermore, you need to have a public DNS entry for the Bitbucket server so that Azure Pipelines can resolve the FQDN of your server to an IP address.
 
-* You can use a **[Other Git](../library/service-endpoints.md#other-git-service-connection)** connection but tell Azure Pipelines not to **attempt accessing this Git server from Azure Pipelines**. CI and PR triggers will not work in this configuration. You can only start manual or scheduled pipeline runs.
+* You can use a **[Other Git](../library/service-endpoints.md#other-git-service-connection)** connection but tell Azure Pipelines not to **attempt accessing this Git server from Azure Pipelines**. CI and PR triggers aren't available with **Other Git** repositories. You can only start manual or scheduled pipeline runs.
 
 ### Reachable from Microsoft-hosted agents
 
-Another decision you possibly have to make is whether to use Microsoft-hosted agents or self-hosted agents to run your pipelines. This often comes down to whether Microsoft-hosted agents can reach your server. To check whether they can, create a pipeline to use Microsoft-hosted agents and make sure to add a step to check out source code from your server. If this passes, then you can continue using Microsoft-hosted agents.
+Another decision you possibly have to make is whether to use Microsoft-hosted agents or self-hosted agents to run your pipelines. This choice often depends on to whether Microsoft-hosted agents can reach your server. To check whether they can, create a pipeline to use Microsoft-hosted agents and make sure to add a step to check out source code from your server. If this passes, then you can continue using Microsoft-hosted agents.
 
 ### Not reachable from Microsoft-hosted agents
 
-If the simple test pipeline mentioned in the above section fails with the error `TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting`, then the Bitbucket server is not reachable from Microsoft-hosted agents. This is again probably caused by a firewall blocking traffic from these servers. You have two options in this case:
+If the simple test pipeline mentioned in the above section fails with the error `TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting`, then the Bitbucket server isn't reachable from Microsoft-hosted agents. This is again probably caused by a firewall blocking traffic from these servers. You have two options in this case:
 
 * Work with your IT department to open a network path between Microsoft-hosted agents and Bitbucket server. See the section on [networking](../agents/hosted.md#agent-ip-ranges) in Microsoft-hosted agents.
 
 * Switch to using [self-hosted agents](../agents/agents.md) or [scale-set agents](../agents/scale-set-agents.md). These agents can be set up within your network and hence will have access to the Bitbucket server. These agents only require outbound connections to Azure Pipelines. There is no need to open a firewall for inbound connections. Make sure that the name of the server you specified when creating the service connection is resolvable from the self-hosted agents.
 
 ## Azure DevOps IP addresses
 
-When you use **Other Git** connection to set up a classic pipeline, disable communication between Azure Pipelines service and Bitbucket server, and use self-hosted agents to build code, you will get a degraded experience:
+When you use **Other Git** connection to set up a classic pipeline, disable communication between Azure Pipelines service and Bitbucket server, and use self-hosted agents to build code, you get a degraded experience:
 
-* You will have to type in the name of the repository manually during pipeline creation
-* You cannot use CI triggers as Azure Pipelines won't be able to poll for changes to the code
-* You cannot use scheduled triggers with the option to build only when there are changes
-* You cannot view information about the latest commit in the user interface
+* You have to type in the name of the repository manually during pipeline creation
+* You can't use CI triggers as Azure Pipelines won't be able to poll for changes to the code
+* You can't use scheduled triggers with the option to build only when there are changes
+* You can't view information about the latest commit in the user interface
 
 If you want to enhance this experience, it is important that you enable communication from Azure Pipelines to Bitbucket Server. 
 
@@ -101,14 +101,14 @@ Follow each of these steps to troubleshoot your failing triggers:
 
 #### I did not push any updates to my code, however the pipeline is still being triggered.
 
-* The continuous integration trigger for Bitbucket works through polling. After each polling interval, Azure Pipelines attempts to contact the Bitbucket server to check if there have been any updates to the code. If Azure Pipelines is unable to reach the Bitbucket server (possibly due to a network issue), then we start a new run anyway assuming that there might have been code changes. When Azure Pipelines cannot retrieve a YAML pipeline's code, it will create an [informational run](../process/information-run.md).
+* The continuous integration trigger for Bitbucket works through polling. After each polling interval, Azure Pipelines attempts to contact the Bitbucket server to check if there have been any updates to the code. If Azure Pipelines is unable to reach the Bitbucket server (possibly due to a network issue), then we start a new run anyway assuming that there might have been code changes. When Azure Pipelines can't retrieve a YAML pipeline's code, it will create an [informational run](../process/information-run.md).
 
 ### Failing checkout
 
 #### When I attempt to start a new run manually, there is a delay of 4-8 minutes before it starts.
 
 * Your Bitbucket server is not reachable from Azure Pipelines. Make sure that you have not selected the option to **attempt accessing this Git server from Azure Pipelines** in the Bitbucket service connection. If that option is selected, Azure Pipelines will attempt to contact to your server and since your server is unreachable, it eventually times out and starts the run anyway. Unchecking that option speeds up your manual runs.
 
-#### The checkout step fails with the error that the server cannot be resolved.
+#### The checkout step fails with the error that the server can't be resolved.
 
 Do you use Microsoft-hosted agents? If so, these agents may not be able to reach your Bitbucket server. See [Not reachable from Microsoft-hosted agents](#not-reachable-from-microsoft-hosted-agents) for more information.