📖 update testgrid links for release docs

docs/release/release-team-onboarding.md

@@ -55,7 +55,7 @@ Now, let's dive into the specific onboarding notes for each sub-team below.
 
 - Start by gaining a general understanding of GitHub labels and how to find issues and pull requests for the current milestone.
 - Familiarize yourself with Prow commands: The Cluster API project utilizes [Prow](https://docs.prow.k8s.io/docs/overview/) to manage CI automation. Issues and PRs are categorized by applying specific list of area labels, which helps in prioritization of that specific issue/PR during the release cycle or release process. Learn more about the available [labels](https://github.com/kubernetes/test-infra/blob/master/label_sync/labels.md#labels-that-apply-to-kubernetes-sigscluster-api-for-both-issues-and-prs) and prow [commands](https://prow.k8s.io/command-help).
-- Take a look at [TestGrid](https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api#Summary), an interactive dashboard for visualizing the CI job results of the project in a grid format!
+- Take a look at [TestGrid](https://testgrid.k8s.io/cluster-api-core) for a high level overview of `main` and the supported release branches' testing status.  Drill into one of the links for an interactive dashboard visualizing the CI job results of that branch in a grid format!
 - Examine the [CI jobs](https://github.com/kubernetes/test-infra/tree/master/config/jobs/kubernetes-sigs/cluster-api) in the test-infra repository. These jobs are defined in YAML and represent various job types, such as periodics and presubmits, that we run in the project.
 - Explore [k8s-triage](https://storage.googleapis.com/k8s-triage/index.html?job=periodic-cluster-api-*), a tool that identifies groups of similar test failures across all jobs.
 - Experiment with running [end-to-end tests](https://cluster-api.sigs.k8s.io/developer/core/testing#running-the-end-to-end-tests-locally) on your local machine to gain a better understanding of the tests and build a confidence debugging CI issues.

docs/release/role-handbooks/ci-signal/README.md

@@ -45,7 +45,7 @@ While we add test coverage for the new release branch we will also drop the test
  ```sh
   TEST_INFRA_DIR=../../k8s.io/test-infra make generate-test-infra-prowjobs
   ```
-6. Verify the jobs and dashboards a day later by taking a look at: `https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api-1.8`
+6. Verify the jobs and dashboards a day later by taking a look at the relevant release branch: `https://testgrid.k8s.io/cluster-api-core`
 
 Prior art:
 
@@ -58,7 +58,7 @@ The goal of this task is to keep our tests running in CI stable.
 **Note**: To be very clear, this is not meant to be an on-call role for Cluster API tests.
 
 1. Add yourself to the [Cluster API alert mailing list](https://github.com/kubernetes/k8s.io/blob/151899b2de933e58a4dfd1bfc2c133ce5a8bbe22/groups/sig-cluster-lifecycle/groups.yaml#L20-L35)
-    <br\>**Note**: An alternative to the alert mailing list is manually monitoring the [testgrid dashboards](https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api)
+    <br\>**Note**: An alternative to the alert mailing list is manually monitoring the [testgrid dashboards](https://testgrid.k8s.io/cluster-api-core)
     (also dashboards of previous releases). Using the alert mailing list has proven to be a lot less effort though.
 2. Subscribe to `CI Activity` notifications for the Cluster API repo.
 3. Check the existing **failing-test** and **flaking-test** issue templates under `.github/ISSUE_TEMPLATE/` folder of the repo, used to create an issue for failing or flaking tests respectively. Please make sure they are up-to-date and if not, send a PR to update or improve them.