Add documentation for merge on red, build analysis, and v1/v2 tests (#…

…84982)

Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>
Co-authored-by: Jeremy Koritzinsky <jkoritzinsky@gmail.com>

.github/ISSUE_TEMPLATE/04_ci_known_issue.yml

@@ -10,7 +10,7 @@ body:
     id: background
     attributes:
       label: Error Blob
-      description: Please identify a clear error string that can help identify future instances of this issue. For more information on how to fill this check https://github.com/dotnet/arcade/blob/main/Documentation/Projects/Build%20Analysis/KnownIssues.md#filling-out-known-issues-json-blob
+      description: Please identify a clear error string that can help identify future instances of this issue. For more information on how to fill this check our issue triage guidelines at [Failure Analysis](/dotnet/runtime/blob/main/docs/workflow/ci/failure-analysis.md#what-to-do-if-you-determine-the-failure-is-unrelated)
       value: |
         ```json
         {

CONTRIBUTING.md

@@ -61,7 +61,7 @@ The best way to create a minimal reproduction is gradually removing code and dep
 
 Project maintainers will merge changes that improve the product significantly.
 
-The [Pull Request Guide](docs/pr-guide.md) and [Copyright](docs/project/copyright.md) docs define additional guidance.
+The [Pull Request Guide](docs/workflow/pr-guide.md) and [Copyright](docs/project/copyright.md) docs define additional guidance.
 
 ### DOs and DON'Ts
 
@@ -113,7 +113,7 @@ We use and recommend the following workflow:
     - Make sure that the tests are all passing, including your new tests.
 7. Create a pull request (PR) against the dotnet/runtime repository's **main** branch.
     - State in the description what issue or improvement your change is addressing.
-    - Check if all the Continuous Integration checks are passing.
+    - Check if all the Continuous Integration checks are passing. Refer to [triaging failures in CI](docs/workflow/ci/failure-analysis.md) to check if any outstanding errors are known.
 8. Wait for feedback or approval of your changes from the [area owners](docs/area-owners.md).
     - Details about the pull request [review procedure](docs/pr-guide.md).
 9. When area owners have signed off, and all checks are green, your PR will be merged.
@@ -165,9 +165,9 @@ The following file header is the used for files in this repo. Please use it for
 
 ### PR - CI Process
 
-The [dotnet continuous integration](https://dev.azure.com/dnceng/public/) (CI) system will automatically perform the required builds and run tests (including the ones you are expected to run) for PRs. Builds and test runs must be clean.
+The [dotnet continuous integration](https://dev.azure.com/dnceng-public/public/_build) (CI) system will automatically perform the required builds and run tests (including the ones you are expected to run) for PRs. Builds and test runs must be clean or have bugs properly filed against flaky/unexpected failures that are unrelated to your change.
 
-If the CI build fails for any reason, the PR issue will be updated with a link that can be used to determine the cause of the failure.
+If the CI build fails for any reason, the PR issue will link to the `Azure DevOps` build with further information on the failure.
 
 ### PR Feedback
 

docs/workflow/README.md

@@ -1,10 +1,13 @@
 # Workflow Guide
 
-* [Build Requirements](#build-requirements)
-* [Getting Yourself Started](#getting-yourself-started)
-* [Configurations and Subsets](#configurations-and-subsets)
-  * [What does this mean for me?](#what-does-this-mean-for-me)
-* [Full Instructions on Building and Testing the Runtime Repo](#full-instructions-on-building-and-testing-the-runtime-repo)
+- [Build Requirements](#build-requirements)
+- [Getting Yourself Started](#getting-yourself-started)
+- [Configurations and Subsets](#configurations-and-subsets)
+  - [What does this mean for me?](#what-does-this-mean-for-me)
+- [Full Instructions on Building and Testing the Runtime Repo](#full-instructions-on-building-and-testing-the-runtime-repo)
+- [Warnings as Errors](#warnings-as-errors)
+- [Submitting a PR](#submitting-a-pr)
+- [Triaging errors in CI](#triaging-errors-in-ci)
 
 The repo can be built for the following platforms, using the provided setup and the following instructions. Before attempting to clone or build, please check the requirements that match your machine, and ensure you install and prepare all as necessary.
 
@@ -91,3 +94,11 @@ And how to measure performance:
 ## Warnings as Errors
 
 The repo build treats warnings as errors. Dealing with warnings when you're in the middle of making changes can be annoying (e.g. unused variable that you plan to use later). To disable treating warnings as errors, set the `TreatWarningsAsErrors` environment variable to `false` before building. This variable will be respected by both the `build.sh`/`build.cmd` root build scripts and builds done with `dotnet build` or Visual Studio. Some people may prefer setting this environment variable globally in their machine settings.
+
+## Submitting a PR
+
+Before submitting a PR, make sure to review the [contribution guidelines](../../CONTRIBUTING.md). After you get familiarized with them, please read the [PR guide](ci/pr-guide.md) to find more information about tips and conventions around creating a PR, getting it reviewed, and understanding the CI results.
+
+## Triaging errors in CI
+
+Given the size of the runtime repository, flaky tests are expected to some degree. There are a few mechanisms we use to help with the discoverability of widely impacting issues. We also have a regular procedure that ensures issues get properly tracked and prioritized. You can find more information on [triaging failures in CI](ci/failure-analysis.md).