[wiki migration] Infra team pages (#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: https://github.com/flutter/assets-for-api-docs/pull/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 https://github.com/flutter/flutter/issues/145009

.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/infra/Adding-a-new-Test-Shard.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/infra/Autorollers.md

@@ -20,7 +20,7 @@ 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>.
 
@@ -28,7 +28,7 @@ Skia also uses an auto-roller for Fuchsia; see <https://autoroll-internal.skia.o
 
 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,7 +41,7 @@ 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:
 
@@ -49,7 +49,7 @@ For example, to generate a description from hash deadbeef to beefdead:
 $ ./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/infra/Flutter-FirebaseLab-Tests.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/infra/How-to-add-a-new-integration-test-to-Framework-CI.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/infra/Infra-Ticket-Queue.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/infra/README.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)

docs/infra/Reducing-Test-Flakiness.md

@@ -3,17 +3,17 @@ Flakiness issue has caused a large portion of the [Flutter tree](https://flutter
 From [Flutter tree dashboard](https://flutter-dashboard.appspot.com/#/build), a flake is identified as a box with an exclamation icon. There are two types that will result in same flaky box.
 * Multiple reruns on the same commit and same task (earlier run fails, but the last run succeeds). For this case, check logs by clicking different build runs.
 
-[[/images/task_flake_multiple_builds.png|width=300px]]
+![Task flakes](https://github.com/flutter/assets-for-api-docs/blob/main/assets/wiki/task_flake_multiple_builds.png)
 
 * A single run on the same commit and same task, but multiple reruns from test runner. For this case, check logs by clicking `stdout` of the test step: it shows data about failed or succeeded runs in the end ([example](https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket.appspot.com/8841146512187805536/+/u/run_build_aar_module_test/stdout)). See https://github.com/flutter/flutter/wiki/Understanding-a-LUCI-build-failure for how to locate the test step and `stdout`.
 
-[[/images/task_flake_test_runner.png|width=300px]]
+![Flake test runner](https://github.com/flutter/assets-for-api-docs/blob/main/assets/wiki/task_flake_test_runner.png)
 
 # Preventing flaky tests
-## [Adding a new DeviceLab test](https://github.com/flutter/flutter/tree/master/dev/devicelab#writing-tests)
-DeviceLab tests are located under [`/dev/devicelab/bin/tasks`](https://github.com/flutter/flutter/tree/master/dev/devicelab/bin/tasks). If you plan to add a new DeviceLab test, please follow
+## [Adding a new DeviceLab test](https://github.com/flutter/flutter/tree/main/dev/devicelab#writing-tests)
+DeviceLab tests are located under [`/dev/devicelab/bin/tasks`](https://github.com/flutter/flutter/tree/main/dev/devicelab/bin/tasks). If you plan to add a new DeviceLab test, please follow
 * Create a PR to add test files
-  * Make sure an ownership entry is created for the test in [TESTOWNERS](https://github.com/flutter/flutter/blob/master/TESTOWNERS) file
+  * Make sure an ownership entry is created for the test in [TESTOWNERS](https://github.com/flutter/flutter/blob/main/TESTOWNERS) file
 * Enable the test in staging pool first
   * Use `bringup: true` in .ci.yaml
   * Monitor the test execution in the [flutter dashboard](https://flutter-dashboard.appspot.com/#/build)
@@ -26,7 +26,7 @@ On a weekly basis, [an automation script](https://github.com/flutter/cocoon/blob
   * Create a tracking bug if not existing in the [bug pool](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+project%3Aflutter%2Fflutter%2F189+label%3A%22team%3A+flakes%22).
     * The sub-team TL will be assigned by default for further triage/re-assign.
     * P0 will be labeled
-  * If it is not a shard test, the script marks the tests as flaky by updating the entry in [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml).
+  * If it is not a shard test, the script marks the tests as flaky by updating the entry in [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml).
     * Add a `# TODO(username): github issue url` above the `bringup: true` line
 
 If an issue is closed, there will be a grace period of 15 days before the automation script refile the issue if the same flakiness persists.
@@ -104,6 +104,6 @@ Sometimes it can be easier to identify patterns of what's different between test
 # Fixing flaky tests
 The TL will help triage, reassign, and attempt to fix the flakiness.
 
-If the test was marked flaky in CI and then fixed, the test can be re-enabled after being validated for 50 consecutive runs without flakiness issues (task without exclamation point in flutter build dashboard and task not failed due to the same flaky failure). This can be done by updating the test entry in [.ci.yaml](https://github.com/flutter/flutter/blob/master/.ci.yaml) to remove the `bringup: true` entry for that target.
+If the test was marked flaky in CI and then fixed, the test can be re-enabled after being validated for 50 consecutive runs without flakiness issues (task without exclamation point in flutter build dashboard and task not failed due to the same flaky failure). This can be done by updating the test entry in [.ci.yaml](https://github.com/flutter/flutter/blob/main/.ci.yaml) to remove the `bringup: true` entry for that target.
 
 If not fixable, the test will be removed from the flutter build dashboard or deleted from CI completely depending on specific cases.

docs/infra/Understanding-a-LUCI-build-failure.md

@@ -1,13 +1,14 @@
-Most tests have been running in Flutter CI [LUCI](https://github.com/flutter/flutter/tree/master/dev/bots#luci-layered-universal-continuous-integration) for multiple flutter repositories, including [post-submit framework](https://flutter-dashboard.appspot.com/#/build), [pre-submit framework](https://ci.chromium.org/p/flutter/g/framework-try/builders), etc. This page uses framework as an example, and talks about what to do when a LUCI build failure happens.
+Most tests have been running in Flutter CI [LUCI](https://github.com/flutter/flutter/tree/main/dev/bots#luci-layered-universal-continuous-integration) for multiple flutter repositories, including [post-submit framework](https://flutter-dashboard.appspot.com/#/build), [pre-submit framework](https://ci.chromium.org/p/flutter/g/framework-try/builders), etc. This page uses framework as an example, and talks about what to do when a LUCI build failure happens.
 
 ## Build dashboards
 * [Flutter build dashboard](https://flutter-dashboard.appspot.com/#/build)
 * [LUCI Milo dashboard](https://ci.chromium.org/p/flutter)
+
 ## Infra Failure
 An infra failure comes with network connection issues, hardware outage, recipe breakage, cipd dependency issues, etc. It shows up as a purple box in the dashboards:
 
-* Framework post-submit build dashboard: [[/images/luci_post_submit_infra_failure.png|alt="two green squares, a red square, and three green squares"]]
-* Framework pre-submit build console: [[/images/luci_pre_submit_infra_failure.png|alt="two green rectangles, a red rectangle, and two more green rectangles"]]
+* Framework post-submit build dashboard: ![three green squares, a purple square, and four green squares, representing build results](https://github.com/flutter/assets-for-api-docs/blob/main/assets/wiki/luci_post_submit_infra_failure.png)
+* Framework pre-submit build console: ![one green rectangle, a purple rectangle, and one more green rectangle, representing build results](https://github.com/flutter/assets-for-api-docs/blob/main/assets/wiki/luci_pre_submit_infra_failure.png)
 
 ### Overview of an infra failure build
 An example build: [Linux color_filter_and_fade_perf__e2e_summary](https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20color_filter_and_fade_perf__e2e_summary/1563/overview)
@@ -19,27 +20,30 @@ An example build: [Linux color_filter_and_fade_perf__e2e_summary](https://ci.chr
 *  (iii) The step list of this builder, defined by the recipe on the right
 *  (iv) The real failed step causing the build failure
 *  (v) Check `stdout` for detailed log
+
 ### What to do
 1. Check if the infra failure has happened on earlier builds by clicking (i)
 2. Check if issue already exists in the [infra bug pool](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3A%22team%3A+infra%22)
-3. If not, file [an infra bug](https://github.com/flutter/flutter/issues/new?assignees=&labels=team%3A+infra&template=6_infrastructure.md&title=)
+3. If not, file [an infra bug](https://github.com/flutter/flutter/issues/new?template=6_infrastructure.yml)
 4. If this is a blocking failure, please add Projects [`Infra Ticket Queue`](https://github.com/flutter/flutter/wiki/Infra-Ticket-Queue). The infra gardener will scan through the queue frequently.
 5. If you want to get an immediate help, please ask in the discord `hackers-infra` channel
 6. If this is an infra flake, and a retry is needed
-   *  For pre-submit test, click `Re-run` in the [check run page](https://github.com/flutter/flutter/pull/83894/checks?check_run_id=2738146673). [[/images/luci_pre_submit_rerun.png|alt=""]]
+   *  For pre-submit test, click `Re-run` in the [check run page](https://github.com/flutter/flutter/pull/83894/checks?check_run_id=2738146673). ![The presubmit rerun interface](https://github.com/flutter/assets-for-api-docs/blob/main/assets/wiki/luci_pre_submit_rerun.png)
       * Limited to `flutter-hackers` group.
-      * Ask a team member to re-run in [[Chat]] channel `#hackers-infra` if you don't have access.
-   *  For post-submit test, login to [framework build dashboard](https://flutter-dashboard.appspot.com/#/build), click the task box, and click `RERUN`. [[/images/luci_post_submit_rerun.png|alt=""]]
+      * Ask a team member to re-run in [Chat](https://github.com/flutter/flutter/wiki/Chat) channel `#hackers-infra` if you don't have access.
+   *  For post-submit test, login to [framework build dashboard](https://flutter-dashboard.appspot.com/#/build), click the task box, and click `RERUN`. ![The post submit rerun interface](https://github.com/flutter/assets-for-api-docs/blob/main/assets/wiki/luci_post_submit_rerun.png)
       * Limited to Googlers currently due to some technical limitations of our infrastructure.
-      * Ask a Googler to re-run in [[Chat]] channel `#hackers-infra`.
+      * Ask a Googler to re-run in [Chat](https://github.com/flutter/flutter/wiki/Chat) channel `#hackers-infra`.
 
 ## Test Failure
 A test failure shows up as a red box in the dashboards:
 
-* Framework post-submit build dashboard: [[/images/luci_post_submit_test_failure.png|alt="three green squares, a purple square, and four green squares"]]
-* Framework pre-submit build console: [[/images/luci_pre_submit_test_failure.png|alt="three green squares, a purple square, and four green squares"]]
+* Framework post-submit build dashboard: ![two green squares, a red square, and three green squares, representing build results](https://github.com/flutter/assets-for-api-docs/blob/main/assets/wiki/luci_post_submit_test_failure.png)
+* Framework pre-submit build console: ![two green squares, a red square, and two green squares, representing build results](https://github.com/flutter/assets-for-api-docs/blob/main/assets/wiki/luci_pre_submit_test_failure.png)
+
 ### Overview of a test failure build
 Please refer to the above example of the infra failure.
+
 ### What to do
 1. Check if it happens in earlier builds/commits via (i)
 2. Debug based on the error message (ii) and detailed log (v) to see if a real test failure caused by code changes.

docs/unsorted_wiki/Engineering-Productivity.md

@@ -1,16 +0,0 @@
-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]]
-- [[Autosubmit bot]]
-- [[Dashboards]]
-- [[Flutter FirebaseLab Tests]]
-- [[Flutter Infrastructure Foundation]]
-- [[Flutter Installation Bundles]]
-- [[Flutter Self Service Index]]
-- [[Flutter Test Fonts]]
-- [Flutter's Build Infrastructure](https://github.com/flutter/flutter/blob/master/dev/bots/README.md)
-- [[Flutter's repository architecture]]
-- [[GitHub Action Workflows]]
-- [[Infra Ticket Queue]]
-- [[Labeling PRs]]
-- [[New Android Version]]