Allow trigger try workfows using labels (#30383)

This change adds and alternate method for triggering try changes.
Instead of comments, changes are triggered via applying labels to pull
requests. The action will remove the label from the request and start
the requested jobs.

This will require creating at least a few labels:

 - T-full
 - T-linux-wpt-2013
 - T-linux-wpt-2020
 - T-macos
 - T-windows

More labels can be added as we support more configurations.

The good thing about this change is that try jobs against the actual
branch in the pull request instead of the master branch. This means
that changes to CI can be tested (unlike for comment processing).

One bit caveat with this change is that when adding multiple labels, a
CI job is triggered for each. Only one real build will run for each
label, but whether or more try jobs is triggered is a race condition.
The first CI job to successfully remove the label will actually trigger
the job. If the same job removes two compatible labels, then they can
share a build (for instance two types of WPT linux jobs). If not there
will be two. Note that this is at least as efficient as the current
behavior.

1 files changed, 5 insertions, 0 deletions

diff --git a/etc/ci/report_aggregated_expected_results.py b/etc/ci/report_aggregated_expected_results.py
index f0046456c27..21c2d6b2431 100755
--- a/etc/ci/report_aggregated_expected_results.py
+++ b/etc/ci/report_aggregated_expected_results.py
@@ -173,6 +173,11 @@ def get_pr_number() -> Optional[str]:
     if "issue" in github_context["event"]:
         return str(github_context["event"]["issue"]["number"])
 
+    # If we have an 'number' in the context, this was triggered by "pull_request" or
+    # "pull_request_target" event.
+    if "number" in github_context["event"]:
+        return str(github_context["event"]["number"])
+
     return None