[wiki migration] Infra team pages (flutter#148718)

This sorts the wiki pages owned by the Infra team in the docs/ directory as planned in [flutter.dev/go/migrate-flutter-wiki-spreadsheet](https://docs.google.com/spreadsheets/d/1x65189ZBdNiLRygpUYoU08pwvXD4M-Z157c6pm8deGI/edit?usp=sharing) 

It also adds the team-infra label to the bot for future PRs.

Image assets were checked in here: flutter/assets-for-api-docs#246

Changes to the content were only updating links. The remaining wiki links will be updated after the rest of the pages are relocated, the original wiki links still work in the meantime.

Part of flutter#145009

Author: Piinks

.github/labeler.yml

@@ -157,6 +157,11 @@ team-engine:
     - any-glob-to-any-file:
       - docs/engine/**/*
 
+team-infra:
+  - changed-files:
+    - any-glob-to-any-file:
+      - docs/infra/**/*
+
 team-release:
   - changed-files:
     - any-glob-to-any-file:

docs/unsorted_wiki/Labeling-PRs.md renamed to docs/contributing/Labeling-PRs.md

@@ -1,19 +1,19 @@
-Further documentation on Flutter's build infrastructure can be found in <https://github.com/flutter/flutter/blob/master/dev/bots/README.md>.
+Further documentation on Flutter's build infrastructure can be found in <https://github.com/flutter/flutter/blob/main/dev/bots/README.md>.
 
 ## Requirements for a Flutter/LUCI build
 
 A general outline of the requirements that a Flutter CI test shard has:
 
 1. On LUCI, test shards map to builders. Each test shard must have its own LUCI builder. For the Framework, these are defined in [framework_config.star](https://flutter.googlesource.com/infra/+/refs/heads/main/config/framework_config.star). Generally you will need to have both a pre-submit ("try" in LUCI terminology) builder and a post-submit ("prod") builder.
-1. This LUCI builder will specify a "recipe" to run. These are [starlark](https://github.com/bazelbuild/starlark) scripts that determine the actual CI steps to run, and are defined in [flutter.googlesource.com/recipes](https://flutter.googlesource.com/recipes). Most Framework tests use the [flutter/flutter_drone.py](https://flutter.googlesource.com/recipes/+/refs/heads/master/recipes/flutter/flutter_drone.py) recipe. To learn how to edit these, see <https://github.com/flutter/flutter/blob/master/dev/bots/README.md#editing-a-recipe>.
-1. Builders are then added to [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml). These files are read by [Flutter's build dashboard](https://flutter-dashboard.appspot.com/#/build), and are used for scheduling builds.
+1. This LUCI builder will specify a "recipe" to run. These are [starlark](https://github.com/bazelbuild/starlark) scripts that determine the actual CI steps to run, and are defined in [flutter.googlesource.com/recipes](https://flutter.googlesource.com/recipes). Most Framework tests use the [flutter/flutter_drone.py](https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/flutter/flutter_drone.py) recipe. To learn how to edit these, see <https://github.com/flutter/flutter/blob/main/dev/bots/README.md#editing-a-recipe>.
+1. Builders are then added to [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml). These files are read by [Flutter's build dashboard](https://flutter-dashboard.appspot.com/#/build), and are used for scheduling builds.
 
 ## Steps to add a new Framework Test Shard
 
 It is important to land these changes in order to prevent any failing builds during the migration period:
 
-1. Framework tests are run by a Dart test runner called [test.dart](https://github.com/flutter/flutter/blob/master/dev/bots/test.dart) that lives in the framework repository. Any new test shards must first be added to this file. Merge this framework change. Note that sharding an existing test doesn't need to update test.dart.
-1. Update [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml) in the Framework tree to include the newly added builder following [CI_YAML.md](https://github.com/flutter/cocoon/blob/main/CI_YAML.md#adding-new-targets). Ensure that the "shard" and "subshard"/"subshards" properties match what was added to test.dart in the previous step. Verify that the entry is marked as `bringup: true`. New shards should always be marked in bringup to verify they are passing on master before being able to block the tree. Merge this change. Note that the new shard will not run in presubmit at this point as the target is with `bringup: true`.
+1. Framework tests are run by a Dart test runner called [test.dart](https://github.com/flutter/flutter/blob/main/dev/bots/test.dart) that lives in the framework repository. Any new test shards must first be added to this file. Merge this framework change. Note that sharding an existing test doesn't need to update test.dart.
+1. Update [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml) in the Framework tree to include the newly added builder following [CI_YAML.md](https://github.com/flutter/cocoon/blob/main/CI_YAML.md#adding-new-targets). Ensure that the "shard" and "subshard"/"subshards" properties match what was added to test.dart in the previous step. Verify that the entry is marked as `bringup: true`. New shards should always be marked in bringup to verify they are passing on master before being able to block the tree. Merge this change. Note that the new shard will not run in presubmit at this point as the target is with `bringup: true`.
 1. Monitor the CI results of the new shard on the [Flutter build dashboard](https://flutter-dashboard.appspot.com/#/build). After 50 consecutive passing builds without any flakes, the flake bot will create a PR to remove the `bringup: true` parameter from `.ci.yaml` in the Framework tree. This will allow the test to block the tree, preventing breakages. With this change, the new shard will start running in presubmit automatically, unless specify `presubmit: false`. Note the flake bot runs once a week on Weds.
 
 Note: if a new post-submit target is renamed from an existing target, there is no need to follow the bringup process.

docs/unsorted_wiki/Adding-a-new-Test-Shard.md renamed to docs/infra/Adding-a-new-Test-Shard.md

@@ -20,15 +20,15 @@ The rollers work by updating a [CIPD](https://chrome-infra-packages.appspot.com/
 
 We use an auto-roller for Skia rolls. It's status can be viewed at <https://skia-flutter-roll.skia.org/>. In case of  build failures or other errors, ping the Flutter-Skia chat channel. In case you get no response, you can login with an @google.com account and pause the roller (or ask someone with an @google.com account to do so). Please specify a descriptive reason and file a bug to re-enable the rollers as soon as possible.
 
-The bot updates the `skia_revision` line of <https://github.com/flutter/engine/blob/master/DEPS>.
+The bot updates the `skia_revision` line of <https://github.com/flutter/engine/blob/main/DEPS>.
 
 Skia also uses an auto-roller for Fuchsia; see <https://autoroll-internal.skia.org/r/fuchsia-autoroll>.
 
 ## Engine to Framework
 
 The engine is automatically rolled to the framework. It is configured by <https://skia.googlesource.com/skia-autoroll-internal-config.git/+/main/skia-infra-public/flutter-engine-flutter.cfg>.
 
-The bot updates <https://github.com/flutter/flutter/blob/master/bin/internal/engine.version> to point to the latest revision of the engine *whose artifacts built successfully*, as determined by looking at the [Engine Console](https://ci.chromium.org/p/flutter/g/engine/console).
+The bot updates <https://github.com/flutter/flutter/blob/main/bin/internal/engine.version> to point to the latest revision of the engine *whose artifacts built successfully*, as determined by looking at the [Engine Console](https://ci.chromium.org/p/flutter/g/engine/console).
 
 
 ### Making a breaking change
@@ -41,15 +41,15 @@ To roll the engine manually in the case you have a breaking change exemption, yo
 
 When you change the `engine.version` file locally, you should delete `$FLUTTER_ROOT/bin/cache` and then run `flutter precache` to ensure that all your local artifacts and snapshots are updated. You can then run tests and be sure that they are running against the latest version of the assets you need.
 
-You may find it helpful to use the [`$ENGINE_ROOT/src/flutter/tools/engine_roll_pr_desc.sh`](https://github.com/flutter/engine/blob/master/tools/engine_roll_pr_desc.sh) to create a PR description. Doing this helps us track down what commits have rolled in more quickly, and properly link to other commits and pull requests for commenting and tracking.
+You may find it helpful to use the [`$ENGINE_ROOT/src/flutter/tools/engine_roll_pr_desc.sh`](https://github.com/flutter/engine/blob/main/tools/engine_roll_pr_desc.sh) to create a PR description. Doing this helps us track down what commits have rolled in more quickly, and properly link to other commits and pull requests for commenting and tracking.
 
 For example, to generate a description from hash deadbeef to beefdead:
 
 ```bash
 $ ./tools/engine_roll_pr_desc.sh deadbeef..beefdead
 ```
 
-_See also: [[Debugging the engine]], which includes instructions on bisecting a roll failure._
+_See also: [Debugging the engine](https://github.com/flutter/flutter/wiki/Debugging-the-engine), which includes instructions on bisecting a roll failure._
 
 
 ## Dart to Engine
@@ -61,6 +61,6 @@ If there are any issues with this process or the autoroller dashboard, contact b
 ## Flutter Pub Roller
 
 The bot account [flutter-pub-roller-bot](https://github.com/flutter-pub-roller-bot) runs the script at
-https://github.com/flutter/flutter/blob/master/dev/conductor/bin/packages_autoroller on post-submit of
+https://github.com/flutter/flutter/blob/main/dev/conductor/bin/packages_autoroller on post-submit of
 every framework commit to keep the pub dependencies in the [framework](https://github.com/flutter/flutter)
 up to date.

docs/unsorted_wiki/Autorollers.md renamed to docs/infra/Autorollers.md

@@ -5,13 +5,13 @@ Flutter FirebaseLab tests are used to build flutter applications and to run them
 These tests consist of two parts:
 
 *   [Firebaselab recipe](https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/firebaselab/firebaselab.py)
-*   [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml#L413) configuration file
+*   [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml#L413) configuration file
 
 The recipe supports three properties: **physical\_devices** to specify actual hardware connected to firebase infra to run tests, **virtual\_devices** to specify the virtual devices(avd) to use and **task\_name** for selecting the integration test to build.
 
 physical\_device and virtual\_device are strings that take the **MODEL\_ID** format defined by firebase. Use `gcloud firebase test android models list` (assuming you have [gcloud](https://cloud.google.com/sdk/gcloud) installed) for a list of possible model id’s.
 
-Task name is the subdirectory of [dev/integration\_tests](https://github.com/flutter/flutter/tree/master/dev/integration_tests) (e.g. android\_views, channels, etc ) that contains the integration test to build.
+Task name is the subdirectory of [dev/integration\_tests](https://github.com/flutter/flutter/tree/main/dev/integration_tests) (e.g. android\_views, channels, etc ) that contains the integration test to build.
 
 The following is an example of the properties format:
 
@@ -51,9 +51,9 @@ This is only required for manually running the steps
 
 ## Adding a Firebaselab Test
 
-*   Step 1: Select the integration test to use from [dev/integration\_tests](https://github.com/flutter/flutter/tree/master/dev/integration_tests)
+*   Step 1: Select the integration test to use from [dev/integration\_tests](https://github.com/flutter/flutter/tree/main/dev/integration_tests)
 *   Step 2: Select the physical and virtual devices to run the test on. You can use `gcloud firebase test android models list` and `gcloud firebase test ios models list` to find the available devices.
-*   Step 3: Write a .ci.yaml target configuration in the [flutter/flutter .ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml) file providing the task\_name, virtual\_devices, physical\_devices and recipe properties.
+*   Step 3: Write a .ci.yaml target configuration in the [flutter/flutter .ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml) file providing the task\_name, virtual\_devices, physical\_devices and recipe properties.
 *   Step 4: Create a PR with the new target. The presubmit checks will run basic validations on yaml format.
 *   Step 5: Wait for the change to propagate.
 *   Step 6: Fix any potential issues and remove `bringup: true` to validate the changes end to end in presubmit.

docs/unsorted_wiki/Autosubmit-bot.md renamed to docs/infra/Autosubmit-bot.md

@@ -1,16 +1,16 @@
-This wiki is for [Framework](https://github.com/flutter/flutter) CI, and is not applicable to other repositories like Engine, Packages. The integration test is referred to an end-to-end target/test presented in [Flutter build dashboard](https://flutter-dashboard.appspot.com/#/build), which is an one-on-one mapping to the entries listed in the [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml) file.
+This wiki is for [Framework](https://github.com/flutter/flutter) CI, and is not applicable to other repositories like Engine, Packages. The integration test is referred to an end-to-end target/test presented in [Flutter build dashboard](https://flutter-dashboard.appspot.com/#/build), which is an one-on-one mapping to the entries listed in the [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml) file.
 
 ## Overview
 Types of integration tests (based on how they are being executed):
 * DeviceLab
-  * Uses test harness: [`test_runner.dart`](https://github.com/flutter/flutter/blob/master/dev/devicelab/bin/test_runner.dart)
+  * Uses test harness: [`test_runner.dart`](https://github.com/flutter/flutter/blob/main/dev/devicelab/bin/test_runner.dart)
   * Relies on recipe: [`devicelab_drone.py`](https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/devicelab/devicelab_drone.py)
   * This consists of two types further
-    * One needs a physical phone (a valid value for either `device_type` or `device_os` in [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml))
-    * The other runs on a host only testbed (either `none` or not defined for both `device_type` or `device_os` in [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml))
+    * One needs a physical phone (a valid value for either `device_type` or `device_os` in [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml))
+    * The other runs on a host only testbed (either `none` or not defined for both `device_type` or `device_os` in [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml))
       * `DeviceLab` here for host only testbed is a legacy name which refers to using the `devicelab_drone.py` recipes and relying on a `task.dart` file defined under `dev/devicelab/bin/tasks`. But this does NOT need a physical device. In the long term, we may want to rename to avoid confusion.
 * Shard
-  * Uses test harness: [`test.dart`](https://github.com/flutter/flutter/blob/master/dev/bots/test.dart)
+  * Uses test harness: [`test.dart`](https://github.com/flutter/flutter/blob/main/dev/bots/test.dart)
   * Relies on recipe: [`flutter_drone.py`](https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/flutter/flutter_drone.py)
   * A `shard` property is defined for these targets
 * Others
@@ -42,15 +42,15 @@ For the two main types (`DeviceLab`/`Shard`):
 
 ## How to add an integration test as a `DeviceLab` target
 
-Please refer to how to write a [`DeviceLab` test](https://github.com/flutter/flutter/tree/master/dev/devicelab#writing-tests) and how to add it to [continuous integration](https://github.com/flutter/flutter/tree/master/dev/devicelab#adding-tests-to-continuous-integration).
+Please refer to how to write a [`DeviceLab` test](https://github.com/flutter/flutter/tree/main/dev/devicelab#writing-tests) and how to add it to [continuous integration](https://github.com/flutter/flutter/tree/main/dev/devicelab#adding-tests-to-continuous-integration).
 
 Quick steps:
 * creates a test file under `dev/devicelab/bin/tasks/<test>.dart`
-* adds a new [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml) entry by mirroring an existing target with `recipe: devicelab_drone` (see .ci.yaml [readme](https://github.com/flutter/cocoon/blob/main/CI_YAML.md))
+* adds a new [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml) entry by mirroring an existing target with `recipe: devicelab_drone` (see .ci.yaml [readme](https://github.com/flutter/cocoon/blob/main/CI_YAML.md))
   * begins with `bringup: true`
   * specifies `device_type` or `device_os` if needed
   * removes `bringup: true` after validated in post-submit CI (in staging pool).
-* adds an ownership entry to [TESTOWNERS](https://github.com/flutter/flutter/blob/master/TESTOWNERS)
+* adds an ownership entry to [TESTOWNERS](https://github.com/flutter/flutter/blob/main/TESTOWNERS)
 * adds entries for other platforms if needed
 
 ## How to add an integration test as a `Shard` target

docs/unsorted_wiki/Dashboards.md renamed to docs/infra/Dashboards.md

@@ -14,10 +14,10 @@ This allows the team to separate their engineering work from ["toil" work](https
 
 IMPORTANT: Whenever you have a request for the infra team, please file a ticket instead of contacting team members directly, even for seemingly trivial things or even if an individual has done the same thing for you in the past. Infra on-call will be there to handle your request, and it lets non on-call team members focus on their engineering tasks.
 
-When in doubt, ask on the `#hackers-infra` channel in [[Chat]].
+When in doubt, ask on the `#hackers-infra` channel in [Chat](https://github.com/flutter/flutter/wiki/Chat).
 
 # How to File a Ticket as an Infra Customer
-1. Open a [new infra issue](https://github.com/flutter/flutter/issues/new?assignees=&labels=team-infra&projects=&template=6_infrastructure.yml). (That template summarizes the information on this page.)
+1. Open a [new infra issue](https://github.com/flutter/flutter/issues/new?template=6_infrastructure.yml). (That template summarizes the information on this page.)
 2. Add a descriptive **title**. A message like "Add a LUCI builder for linux web engine" or "Debug gallery startup" is much more helpful than "quick request" or "test doesn't work?".
 3. Clearly describe the issue or request in the description field. For example, if a ticket is requesting running several commands on the bots, the ticket should explain why, what commands are needed, on which bots and how to verify the results.
 4. Skip the priority label which infra on-call will add after triaging.

docs/unsorted_wiki/Flutter-FirebaseLab-Tests.md renamed to docs/infra/Flutter-FirebaseLab-Tests.md

@@ -0,0 +1,16 @@
+This is an index of team-facing documentation for topics relating to Engineering Productivity (also known as EngProd, and including topics relating to our CI infrastructure, security, autorollers, etc).
+
+- [Autorollers](Autorollers.md)
+- [Autosubmit bot](Autosubmit-bot.md)
+- [Dashboards](Dashboards.md)
+- [Flutter FirebaseLab Tests](Flutter-FirebaseLab-Tests.md)
+- [Flutter Infrastructure Foundation](Flutter-Infrastructure-Foundation.md)
+- [Flutter Installation Bundles](Flutter-Installation-Bundles.md)
+- [Flutter Self Service Index](https://github.com/flutter/flutter/wiki/Flutter-Self-Service-Index)
+- [Flutter Test Fonts](https://github.com/flutter/flutter/wiki/Flutter-Test-Fonts)
+- [Flutter's Build Infrastructure](../../dev/bots/README.md)
+- [Flutter's repository architecture](https://github.com/flutter/flutter/wiki/Flutter%27s-repository-architecture)
+- [GitHub Action Workflows](GitHub-Action-Workflows.md)
+- [Infra Ticket Queue](Infra-Ticket-Queue.md)
+- [Labeling PRs](../contributing/Labeling-PRs.md)
+- [New Android Version](https://github.com/flutter/flutter/wiki/New-Android-version)