Clarifications for DTSes in July

Author: vijaymatest1

docs/pipelines/process/scheduled-triggers.md

@@ -449,7 +449,7 @@ In this example, the classic editor scheduled trigger has two entries, producing
 
 * You might have updated the service connection used to connect to the repository. This will cause a new run to be scheduled even if you have not updated your source code.
 
-* Azure Pipelines first checks if there are any updates to your code. If Azure Pipelines is unable to reach your repository or get this information, it will either start a scheduled run anyway or it will create a failed run to indicate that it is unable to reach the repository.
+* Azure Pipelines first checks if there are any updates to your code. If Azure Pipelines is unable to reach your repository or get this information, it will either start a scheduled run anyway or it will create a failed run to indicate that it is unable to reach the repository. If you notice that a run was created and that failed immediately, this is likely the reason. It is a dummy build to let you know that Azure Pipelines is unable to reach your repository.
 
 ### I see the planned run in the Scheduled runs panel. However, it does not run at that time. Why?
 

docs/pipelines/repos/azure-repos-git.md

@@ -222,7 +222,11 @@ Problems related to Azure Repos integration fall into three categories:
 
 [!INCLUDE [qa](includes/qa3.md)]
 
-#### I have the YAML file in one repo and the application code in a different repo. How do I set up the pipeline to be triggered by changes to application code?
+[!INCLUDE [qa](includes/qa4.md)]
+
+#### I have multiple repositories in my YAML pipeline. How do I set up triggers for each repository?
+
+See triggers in [Using multiple repositories](multi-repo-checkout.md#triggers).
 
 ### Failing checkout
 

docs/pipelines/repos/bitbucket.md

@@ -219,6 +219,8 @@ Problems related to Bitbucket integration fall into the following categories:
 
 [!INCLUDE [qa](includes/qa3.md)]
 
+[!INCLUDE [qa](includes/qa4.md)]
+
 ### Wrong version
 
 [!INCLUDE [qa](includes/qa1.md)]

docs/pipelines/repos/github.md

@@ -564,6 +564,14 @@ Depending on the authentication type and ownership of the repository, specific p
 - If you're using OAuth, see [OAuth authentication](#oauth-authentication).
 - If you're using PATs, see [Personal access token (PAT) authentication](#personal-access-token-pat-authentication).
 
+#### When I select a repository during pipeline creation, I get an error "The repository <repo-name> is in use with the Azure Pipelines GitHub App in another Azure DevOps organization."
+
+This means that your repository is already associated with a pipeline in a different organization. CI and PR events from this repository won't work as they will be delivered to the other organization. Here are the steps you should take to remove the mapping to the other organization before proceeding to create a pipeline.
+
+  1. Open a pull request in your GitHub repository, and make the comment `/azp where`. This reports back the Azure DevOps organization that the repository is mapped to. 
+  
+  2. To change the mapping, uninstall the app from the GitHub organization, and re-install it. As you re-install it, make sure to select the correct organization when you are redirected to Azure DevOps.
+
 ### Failing triggers
 
 [!INCLUDE [qa](includes/qa2.md)]
@@ -588,6 +596,8 @@ Depending on the authentication type and ownership of the repository, specific p
 
 [!INCLUDE [qa](includes/qa3.md)]
 
+[!INCLUDE [qa](includes/qa4.md)]
+
 ### Failing checkout
 
 #### I see the following error in the log file during checkout step. How do I fix it?

docs/pipelines/repos/includes/qa4.md

@@ -0,0 +1,19 @@
+---
+ms.topic: include
+ms.technology: devops-cicd
+ms.manager: mijacobs
+ms.author: vijayma
+author: vijayma
+ms.date: 07/29/2020
+---
+
+#### I do not want users to override the list of branches for triggers when they checkout the YAML file. How can I do this?
+
+Users with permissions to contribute code can update the YAML file and include/exclude additional branches. As a result, users can include their own feature or user branch in their YAML file and push that update to a feature or user branch. This may cause the pipeline to be triggered for all updates to that branch. If you want to prevent this behavior, then you can:
+
+  1. Edit the pipeline in the Azure Pipelines UI.
+  2. Navigate to the **Triggers** menu.
+  3. Select **Override the YAML continuous Integration trigger from here**.
+  4. Specify the branches to include or exclude for the trigger.
+
+Note that when you follow these steps, any CI triggers specified in the YAML file are ignored.

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

@@ -94,6 +94,10 @@ Follow each of these steps to troubleshoot your failing triggers:
 
 * Have you excluded the branches or paths to which you pushed your changes? Test by pushing a change to an included path in an included branch. Note that paths in triggers are case-sensitive. Make sure that you use the same case as those of real folders when specifying the paths in 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. In a few cases, Azure Pipelines may also create a dummy failed build with an error message to indicate that it was unable to reach the server.
+
 ### Failing checkout
 
 #### When I attempt to start a new run manually, there is a delay of 4-8 minutes before it starts.

docs/pipelines/repos/subversion.md

@@ -58,6 +58,10 @@ Follow each of these steps to troubleshoot your failing triggers:
 
 * Is your pipeline paused or disabled? Open the editor for the pipeline, and then select **Settings** to check. If your pipeline is paused or disabled, then triggers do not work.
 
+#### I did not push any updates to my code, however the pipeline is still being triggered.
+
+* The continuous integration trigger for Subversion works through polling. After each polling interval, Azure Pipelines attempts to contact the Subversion server to check if there have been any updates to the code. If Azure Pipelines is unable to reach the server (possibly due to a network issue), then we start a new run anyway assuming that there might have been code changes. In a few cases, Azure Pipelines may also create a dummy failed build with an error message to indicate that it was unable to reach the server.
+
 ### Failing checkout
 
 #### The checkout step fails with the error that the server cannot be resolved.