diff --git a/docs/release/release-team-onboarding.md b/docs/release/release-team-onboarding.md index a20c583543fe..33b0d07545d2 100644 --- a/docs/release/release-team-onboarding.md +++ b/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. \ No newline at end of file diff --git a/docs/release/role-handbooks/ci-signal/README.md b/docs/release/role-handbooks/ci-signal/README.md index 3808d23ce724..6c6512ae5dec 100644 --- a/docs/release/role-handbooks/ci-signal/README.md +++ b/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) - **Note**: An alternative to the alert mailing list is manually monitoring the [testgrid dashboards](https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api) + **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.