Global replace of the new win10 CQ bot's name in various docs/comments

The builder was renamed to "win-rel" as part of crbug.com/1381274. It
should have the exact same behavior. So any doc or comment that
mentions it has been updated to the new name here.

Although web_tests' references were unchanged. Filed crbug.com/1383534
to cover those since they seem to have some effect on behavior.

Bug: 1381274
Change-Id: I9204dee6f58dd34826de3a0b3a8372ec5f7e5e43
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4022168
Reviewed-by: Brian Sheedy <bsheedy@chromium.org>
Reviewed-by: Joshua Pawlicki <waffles@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Kevin McNee <mcnee@chromium.org>
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1071119}

chrome/browser/apps/guest_view/web_view_browsertest.cc

@@ -6174,8 +6174,8 @@ IN_PROC_BROWSER_TEST_F(SitePerProcessWebViewTest, ContentScript) {
 
 // Checks that content scripts work in an out-of-process iframe in a <webview>
 // tag.
-// TODO(crbug.com/1363124): Fix flakiness on win10_chromium_x64_rel_ng. The test
-// is also disabled on mac11-arm64-rel using filter.
+// TODO(crbug.com/1363124): Fix flakiness on win-rel. The test is also disabled
+// on mac11-arm64-rel using filter.
 #if BUILDFLAG(IS_WIN)
 #define MAYBE_ContentScriptInOOPIF DISABLED_ContentScriptInOOPIF
 #else

chrome/updater/win/BUILD.gn

@@ -33,9 +33,8 @@ source_set("updater_executable") {
   ]
 
   # `updater.rc` does not process `#if BUILDFLAG(GOOGLE_CHROME_BRANDING)`
-  # correctly sometimes, especially seen with the `win10_chromium_x64_rel_ng`
-  # build bot. Explicitly defining `CHROME_BRANDED_TLB` is being done here as a
-  # workaround.
+  # correctly sometimes, especially seen with the `win-rel` builder. Explicitly
+  # defining `CHROME_BRANDED_TLB` is being done here as a workaround.
   if (is_chrome_branded) {
     defines = [ "CHROME_BRANDED_TLB=1" ]
   } else {

components/content_capture/browser/content_capture_receiver_test.cc

@@ -174,8 +174,8 @@ TEST_P(ContentCaptureReceiverTest, MultipleConsumers) {
   EXPECT_EQ(consumer(), provider()->GetConsumersForTesting()[0]);
 }
 
-// TODO(https://crbug.com/1010179): Fix flakes on win10_chromium_x64_rel_ng and
-// re-enable this test.
+// TODO(https://crbug.com/1010179): Fix flakes on win-rel and re-enable this
+// test.
 #if BUILDFLAG(IS_WIN)
 #define MAYBE_DidCaptureContentWithUpdate DISABLED_DidCaptureContentWithUpdate
 #else
@@ -202,8 +202,8 @@ TEST_P(ContentCaptureReceiverTest, MAYBE_DidCaptureContentWithUpdate) {
             consumer()->captured_data());
 }
 
-// TODO(https://crbug.com/1011204): Fix flakes on win10_chromium_x64_rel_ng and
-// re-enable this test.
+// TODO(https://crbug.com/1011204): Fix flakes on win-rel and re-enable this
+// test.
 #if BUILDFLAG(IS_WIN)
 #define MAYBE_DidUpdateContent DISABLED_DidUpdateContent
 #else
@@ -362,8 +362,8 @@ TEST_P(ContentCaptureReceiverTest, TitleUpdateTaskDelay) {
   EXPECT_EQ(title2, consumer()->updated_title());
 }
 
-// TODO(https://crbug.com/1010416): Fix flakes on win10_chromium_x64_rel_ng and
-// re-enable this test.
+// TODO(https://crbug.com/1010416): Fix flakes on win-rel and re-enable this
+// test.
 #if BUILDFLAG(IS_WIN)
 #define MAYBE_ChildFrameCaptureContentFirst \
   DISABLED_ChildFrameCaptureContentFirst
@@ -562,8 +562,8 @@ class ContentCaptureReceiverMultipleFrameTest
   ContentCaptureTestHelper helper_;
 };
 
-// TODO(https://crbug.com/1010417): Fix flakes on win10_chromium_x64_rel_ng and
-// re-enable this test.
+// TODO(https://crbug.com/1010417): Fix flakes on win-rel and re-enable this
+// test.
 #if BUILDFLAG(IS_WIN)
 #define MAYBE_ReceiverCreatedForExistingFrame \
   DISABLED_ReceiverCreatedForExistingFrame

docs/gpu/gpu_testing.md

@@ -112,11 +112,11 @@ of the following tryservers' jobs:
 
 *   [linux-rel], formerly on the `tryserver.chromium.linux` waterfall
 *   [mac-rel], formerly on the `tryserver.chromium.mac` waterfall
-*   [win10_chromium_x64_rel_ng], formerly on the `tryserver.chromium.win` waterfall
+*   [win-rel], formerly on the `tryserver.chromium.win` waterfall
 
-[linux-rel]:                 https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux-rel?limit=100
-[mac-rel]:                   https://ci.chromium.org/p/chromium/builders/luci.chromium.try/mac-rel?limit=100
-[win10_chromium_x64_rel_ng]: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win10_chromium_x64_rel_ng?limit=100
+[linux-rel]: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux-rel?limit=100
+[mac-rel]:   https://ci.chromium.org/p/chromium/builders/luci.chromium.try/mac-rel?limit=100
+[win-rel]:   https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win-rel?limit=100
 
 Scan down through the steps looking for the text "GPU"; that identifies those
 tests run on the GPU bots. For each test the "trigger" step can be ignored; the

docs/gpu/gpu_testing_bot_details.md

@@ -55,15 +55,15 @@ queries of the bots and see, for example, which GPUs are available.
 The waterfall bots run tests on a single GPU type in order to make it easier to
 see regressions or flakiness that affect only a certain type of GPU.
 
-The tryservers like `win10_chromium_x64_rel_ng` which include GPU tests, on the
-other hand, run tests on more than one GPU type. As of this writing, the Windows
-tryservers ran tests on NVIDIA and Intel GPUs; the Mac tryservers ran tests on
-Intel and AMD GPUs. The way these tryservers' tests are specified is simply
-by *mirroring* how one or more waterfall bots work. This is an inherent
-property of the [`chromium_trybot` recipe][chromium_trybot.py], which was
-designed to eliminate differences in behavior between the tryservers and
-waterfall bots. Since the tryservers mirror waterfall bots, if the waterfall bot
-is working, the tryserver must almost inherently be working as well.
+The tryservers like `win-rel` which include GPU tests, on the other hand, run
+tests on more than one GPU type. As of this writing, the Windows tryservers ran
+tests on NVIDIA and Intel GPUs; the Mac tryservers ran tests on Intel and AMD
+GPUs. The way these tryservers' tests are specified is simply by *mirroring*
+how one or more waterfall bots work. This is an inherent property of the
+[`chromium_trybot` recipe][chromium_trybot.py], which was designed to eliminate
+differences in behavior between the tryservers and waterfall bots. Since the
+tryservers mirror waterfall bots, if the waterfall bot is working, the
+tryserver must almost inherently be working as well.
 
 [chromium_trybot.py]: https://chromium.googlesource.com/chromium/tools/build/+/main/recipes/recipes/chromium_trybot.py
 
@@ -431,9 +431,9 @@ https://luci-scheduler.appspot.com/.
 
 ### How to start running tests on a new GPU type on an existing try bot
 
-Let's say that you want to cause the `win10_chromium_x64_rel_ng` try bot to run
-tests on CoolNewGPUType in addition to the types it currently runs (as of this
-writing only NVIDIA). To do this:
+Let's say that you want to cause the `win-rel` try bot to run tests on
+CoolNewGPUType in addition to the types it currently runs (as of this writing
+only NVIDIA). To do this:
 
 1.  Make sure there is enough hardware capacity using the available tools to
     report utilization of the Swarming pool.
@@ -442,7 +442,7 @@ writing only NVIDIA). To do this:
     the flakiness on the new bots is comparable to existing `chromium.gpu` bots
     before proceeding.
 1.  Create a CL in the [`chromium/src`][chromium/src] workspace that adds the
-    new Release tester to `win10_chromium_x64_rel_ng`'s `mirrors` list. Rerun
+    new Release tester to `win-rel`'s `mirrors` list. Rerun
     `infra/config/main.star`.
 1.  Once the above CL lands, the commit queue will **immediately** start
     running tests on the CoolNewGPUType configuration. Be vigilant and make