Fix broken links to testgrid dashboard

release-engineering/role-handbooks/branch-manager.md

@@ -307,7 +307,7 @@ hardware architectures.
 
 <!-- TODO: krel is not checking testgrid
 
-Early in the release cycle, it is likely that the build might fail. By default the `stage master` command automatically looks for a place where [release master blocking tests](https://k8s-testgrid.appspot.com/sig-release-master-blocking) have green results, which traditionally has not happened in Kubernetes on an ongoing basis.
+Early in the release cycle, it is likely that the build might fail. By default the `stage master` command automatically looks for a place where [release master blocking tests](https://testgrid.k8s.io/sig-release-master-blocking) have green results, which traditionally has not happened in Kubernetes on an ongoing basis.
 
 WE REALLY WANT (and need) TO GET THERE. Quality needs to be a continual focus. But in the meantime, acknowledging today especially for an early alpha or beta release, it is possible to just build via:
 

release-engineering/role-handbooks/patch-release-team.md

@@ -428,7 +428,7 @@ cell to indicate the uncertainty.
 
 Keep an eye on approved cherry-pick PRs to make sure they aren't getting blocked
 on presubmits that are failing across the whole branch.
-Also periodically check the [testgrid](https://k8s-testgrid.appspot.com)
+Also periodically check the [testgrid](https://testgrid.k8s.io)
 dashboard for your release branch to make sure the continuous jobs are healthy.
 
 Escalate to test owners,

release-team/README.md

@@ -51,7 +51,7 @@ which shall be the discharged by the Release Team.
   - Announcement of alpha, beta, release candidate availability
   - Announcement of release availability
 - Deriving signal from the following sources
-  - [test grid](https://k8s-testgrid.appspot.com/)
+  - [test grid](https://testgrid.k8s.io/)
   - GitHub [flake issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Akind%2Fflake)
   - GitHub [bug issues](https://github.com/kubernetes/kubernetes/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3Akind%2Fbug)
 - Identifying owning individuals and SIGs for blocking issues

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

@@ -36,7 +36,7 @@
 
 CI Signal lead assumes the responsibility of the quality gate for the release. This person is responsible for:
 
--   Continuously monitoring various e2e tests in sig-release dashboards ([master-blocking](https://k8s-testgrid.appspot.com/sig-release-master-blocking), [master-informing](https://k8s-testgrid.appspot.com/sig-release-master-informing), `release-x.y-blocking/informing` (x.y being the current release)) throughout the release cycle
+-   Continuously monitoring various e2e tests in sig-release dashboards ([master-blocking](https://testgrid.k8s.io/sig-release-master-blocking), [master-informing](https://testgrid.k8s.io/sig-release-master-informing), `release-x.y-blocking/informing` (x.y being the current release)) throughout the release cycle
 -   Providing early and ongoing signals on release and test health to both Release team and various SIGs
 -   Ensuring that all release blocking tests provide a clear Go/No-Go signal for the release
 -   Flagging regressions as close to source as possible i.e., as soon as the offending code was merged
@@ -117,7 +117,7 @@ Here are some good early deliverables from the CI Signal lead between start of t
 
 -   Start maintain the [CI signal project board](https://github.com/orgs/kubernetes/projects/68) and keep it up-to-date with issues tracking any test failure/flake
 -   Assign the new milestone labels to the open issues from previous release, assign a member of the CI signal team, and have that member follow up on the issue with owners
--   Monitor [master-blocking](https://k8s-testgrid.appspot.com/sig-release-master-blocking) and [master-informing](https://testgrid.k8s.io/sig-release-master-informing) dashboards **twice a week** and ensure all failures and flakes are tracked via open issues. See [Opening Issues](#opening-issues) for how to write an effective issue.
+-   Monitor [master-blocking](https://testgrid.k8s.io/sig-release-master-blocking) and [master-informing](https://testgrid.k8s.io/sig-release-master-informing) dashboards **twice a week** and ensure all failures and flakes are tracked via open issues. See [Opening Issues](#opening-issues) for how to write an effective issue.
 -   Build and maintain a document of area experts / owners across SIGs for future needs e.g.: Scalability experts, upgrade test experts etc
 
 #### **_Best Practice:_**
@@ -128,8 +128,8 @@ The SLA and involvement of signal lead at this stage might vary from release to
 
 Day to day tasks remain pretty much the same as before, with the following slight changes
 
--   Monitor [master-blocking](https://k8s-testgrid.appspot.com/sig-release-master-blocking) dashboard **daily**
--   Monitor [master-informing](https://k8s-testgrid.appspot.com/sig-release-master-informing) **every other day**
+-   Monitor [master-blocking](https://testgrid.k8s.io/sig-release-master-blocking) dashboard **daily**
+-   Monitor [master-informing](https://testgrid.k8s.io/sig-release-master-informing) **every other day**
 
 Increased attention on maintaining signal early in the release cycle goes a long way in reducing the risk of late-found issues destabilizing the release during code freeze.
 

releases/release-1.10/README.md

@@ -15,7 +15,7 @@
 
 * The feature process is remaining as it has in prior releases. 
 * Features that don't have complete code and tests by [Code Freeze](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.10/release-1.10.md#code-freeze) may be disabled by the release team before cutting the first beta.
-* The release team will escalate [release-master-blocking](https://k8s-testgrid.appspot.com/sig-release-master-blocking) failures to SIGs throughout the cycle, not just near release cuts.
+* The release team will escalate [release-master-blocking](https://testgrid.k8s.io/sig-release-master-blocking) failures to SIGs throughout the cycle, not just near release cuts.
 * Key deliverables (e.g. initial release cuts) tend to be scheduled on Tuesdays to maintain context while ramping up and then responding to any problems.  The final release will be on a Wednesday in keeping with prior practice.
 * The release length is nearly 12 weeks
 * Code name "*Left Shark*" because it's been my favorite meme of the release cycle (Thanks [Christoph](https://github.com/cblecker))