renaming all references to jetstack/testing

ref: cert-manager/testing#904

Signed-off-by: Maël Valais <[email protected]>

README.md

@@ -180,7 +180,7 @@ This will automatically run a number of checks against your local environment, i
 
 > ℹ️ All these checks are also run automatically for pull requests.
 > The results will be reported in the [checks summary](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks) at the bottom of your GitHub PR.
-> Read the [cert-manager-website-presubmits.yaml prow configuration file](https://github.com/jetstack/testing/blob/master/config/jobs/cert-manager/website/cert-manager-website-presubmits.yaml) and the [check.yaml workflow file](.github/workflows/check.yaml) for more details.
+> Read the [cert-manager-website-presubmits.yaml prow configuration file](https://github.com/cert-manager/testing/blob/master/config/jobs/cert-manager/website/cert-manager-website-presubmits.yaml) and the [check.yaml workflow file](.github/workflows/check.yaml) for more details.
 
 ### Building for a Release
 

content/docs/contributing/e2e.md

@@ -137,7 +137,7 @@ The master branch of cert-manager can also be tested against different cloud pro
 
 The infrastructure used to run the e2e tests on cloud providers is present in the [cert-manager/test-infra](https://github.com/cert-manager/test-infra) repository. More cloud providers can be added by creating infrastructure for them using [Terraform](https://www.terraform.io/).
 
-Apart from that, tests for the existing infrastructure can be customized by editing their respective prow jobs present in the [Jetstack testing repository](https://github.com/jetstack/testing/tree/master/config/jobs/cert-manager) repository. Values like the cert-manager version or the cloud provider version are present as variables in Terraform so their values can be changed when using `terraform apply` in the prow jobs, for example, for the [EKS prow job](https://github.com/jetstack/testing/blob/master/config/jobs/cert-manager/cert-manager-periodics.yaml#L524) the cert-manager version being tested can be changed using
+Apart from that, tests for the existing infrastructure can be customized by editing their respective prow jobs present in the [Jetstack testing repository](https://github.com/cert-manager/testing/tree/master/config/jobs/cert-manager) repository. Values like the cert-manager version or the cloud provider version are present as variables in Terraform so their values can be changed when using `terraform apply` in the prow jobs, for example, for the [EKS prow job](https://github.com/cert-manager/testing/blob/master/config/jobs/cert-manager/cert-manager-periodics.yaml#L524) the cert-manager version being tested can be changed using
 
 ```console
 terraform apply -var="cert_manager_version=v1.3.3" -auto-approve

content/docs/contributing/release-process.md

@@ -365,7 +365,7 @@ page if a step is missing or if it is outdated.
        We don't fast-forward for patch releases and final releases; instead, we
        prepare these releases using the `/cherry-pick release-1.0` command.
 
-   > Note about branch protection: The release branches are protected by [GitHub branch protection](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule), which is [configured automatically by Prow](https://github.com/jetstack/testing/blob/500b990ad1278982b10d57bf8fbca383040d2fe8/config/config.yaml#L27-L36).
+   > Note about branch protection: The release branches are protected by [GitHub branch protection](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule), which is [configured automatically by Prow](https://github.com/cert-manager/testing/blob/500b990ad1278982b10d57bf8fbca383040d2fe8/config/config.yaml#L27-L36).
    >  This prevents anyone *accidentally* pushing changes directly to these branches, even repository administrators.
    >  If you need, for some reason, to fast forward the release branch,
    >  you should delete the branch protection for that release branch, using the [GitHub branch protection web UI](https://github.com/cert-manager/cert-manager/settings/branches).
@@ -658,11 +658,11 @@ page if a step is missing or if it is outdated.
 
     1. **(initial beta only)** Create a PR on
        [cert-manager/release](https://github.com/cert-manager/release) in order to
-       add the new release to our list of periodic ProwJobs. Use [this PR](https://github.com/jetstack/testing/pull/774/) as an example.
+       add the new release to our list of periodic ProwJobs. Use [this PR](https://github.com/cert-manager/testing/pull/774/) as an example.
 
     2. **(initial beta only)** Run `cmrel generate-prow --branch='*' -o file` with the new version from the previous step and
-       open a PR to [cert-manager/testing](https://github.com/jetstack/testing) adding the generated prow configs.
-       Use [this PR](https://github.com/jetstack/testing/pull/766) as an example.
+       open a PR to [cert-manager/testing](https://github.com/cert-manager/testing) adding the generated prow configs.
+       Use [this PR](https://github.com/cert-manager/testing/pull/766) as an example.
 
     3. **(final release only)** Create a PR on
        [cert-manager/release](https://github.com/cert-manager/release),
@@ -675,10 +675,10 @@ page if a step is missing or if it is outdated.
        This will remove the periodic ProwJobs for this version as they're no longer needed.
 
     4. **(final release only)** Run `cmrel generate-prow --branch='*' -o file` with the new version from the previous step and
-       open a PR to [jetstack/testing](https://github.com/jetstack/testing) adding the generated prow configs.
+       open a PR to [jetstack/testing](https://github.com/cert-manager/testing) adding the generated prow configs.
 
-    5. **(final release only)** Open a PR to [`jetstack/testing`](https://github.com/jetstack/testing)
-       and update the [milestone_applier](https://github.com/jetstack/testing/blob/3110b68e082c3625bf0d26265be2d29e41da14b2/config/plugins.yaml#L69)
+    5. **(final release only)** Open a PR to [`jetstack/testing`](https://github.com/cert-manager/testing)
+       and update the [milestone_applier](https://github.com/cert-manager/testing/blob/3110b68e082c3625bf0d26265be2d29e41da14b2/config/plugins.yaml#L69)
        config so that newly raised PRs on master are applied to a new milestone
        for the next release. E.g. if master currently points at the `v1.10` milestone, change it to point at `v1.11`.
 

content/v1.12-docs/contributing/e2e.md

@@ -137,7 +137,7 @@ The master branch of cert-manager can also be tested against different cloud pro
 
 The infrastructure used to run the e2e tests on cloud providers is present in the [cert-manager/test-infra](https://github.com/cert-manager/test-infra) repository. More cloud providers can be added by creating infrastructure for them using [Terraform](https://www.terraform.io/).
 
-Apart from that, tests for the existing infrastructure can be customized by editing their respective prow jobs present in the [Jetstack testing repository](https://github.com/jetstack/testing/tree/master/config/jobs/cert-manager) repository. Values like the cert-manager version or the cloud provider version are present as variables in Terraform so their values can be changed when using `terraform apply` in the prow jobs, for example, for the [EKS prow job](https://github.com/jetstack/testing/blob/master/config/jobs/cert-manager/cert-manager-periodics.yaml#L524) the cert-manager version being tested can be changed using
+Apart from that, tests for the existing infrastructure can be customized by editing their respective prow jobs present in the [Jetstack testing repository](https://github.com/cert-manager/testing/tree/master/config/jobs/cert-manager) repository. Values like the cert-manager version or the cloud provider version are present as variables in Terraform so their values can be changed when using `terraform apply` in the prow jobs, for example, for the [EKS prow job](https://github.com/cert-manager/testing/blob/master/config/jobs/cert-manager/cert-manager-periodics.yaml#L524) the cert-manager version being tested can be changed using
 
 ```console
 terraform apply -var="cert_manager_version=v1.3.3" -auto-approve

content/v1.12-docs/contributing/release-process.md

@@ -218,7 +218,7 @@ page if a step is missing or if it is outdated.
        We don't fast-forward for patch releases and final releases; instead, we
        prepare these releases using the `/cherry-pick release-1.0` command.
 
-   > Note about branch protection: The release branches are protected by [GitHub branch protection](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule), which is [configured automatically by Prow](https://github.com/jetstack/testing/blob/500b990ad1278982b10d57bf8fbca383040d2fe8/config/config.yaml#L27-L36).
+   > Note about branch protection: The release branches are protected by [GitHub branch protection](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule), which is [configured automatically by Prow](https://github.com/cert-manager/testing/blob/500b990ad1278982b10d57bf8fbca383040d2fe8/config/config.yaml#L27-L36).
    >  This prevents anyone *accidentally* pushing changes directly to these branches, even repository administrators.
    >  If you need, for some reason, to fast forward the release branch,
    >  you should delete the branch protection for that release branch, using the [GitHub branch protection web UI](https://github.com/cert-manager/cert-manager/settings/branches).
@@ -493,11 +493,11 @@ page if a step is missing or if it is outdated.
 
     1. **(initial beta only)** Create a PR on
        [cert-manager/release](https://github.com/cert-manager/release) in order to
-       add the new release to our list of periodic ProwJobs. Use [this PR](https://github.com/jetstack/testing/pull/774/) as an example.
+       add the new release to our list of periodic ProwJobs. Use [this PR](https://github.com/cert-manager/testing/pull/774/) as an example.
 
     2. **(initial beta only)** Run `cmrel generate-prow --branch='*' -o file` with the new version from the previous step and
-       open a PR to [cert-manager/testing](https://github.com/jetstack/testing) adding the generated prow configs.
-       Use [this PR](https://github.com/jetstack/testing/pull/766) as an example.
+       open a PR to [cert-manager/testing](https://github.com/cert-manager/testing) adding the generated prow configs.
+       Use [this PR](https://github.com/cert-manager/testing/pull/766) as an example.
 
     3. If needed, open a PR to
        [`cert-manager/website`](https://github.com/cert-manager/website) in
@@ -518,10 +518,10 @@ page if a step is missing or if it is outdated.
        This will remove the periodic ProwJobs for this version as they're no longer needed.
 
     5. **(final release only)** Run `cmrel generate-prow --branch='*' -o file` with the new version from the previous step and
-       open a PR to [jetstack/testing](https://github.com/jetstack/testing) adding the generated prow configs.
+       open a PR to [jetstack/testing](https://github.com/cert-manager/testing) adding the generated prow configs.
 
-    6. **(final release only)** Open a PR to [`jetstack/testing`](https://github.com/jetstack/testing)
-       and update the [milestone_applier](https://github.com/jetstack/testing/blob/3110b68e082c3625bf0d26265be2d29e41da14b2/config/plugins.yaml#L69)
+    6. **(final release only)** Open a PR to [`jetstack/testing`](https://github.com/cert-manager/testing)
+       and update the [milestone_applier](https://github.com/cert-manager/testing/blob/3110b68e082c3625bf0d26265be2d29e41da14b2/config/plugins.yaml#L69)
        config so that newly raised PRs on master are applied to a new milestone
        for the next release. E.g. if master currently points at the `v1.10` milestone, change it to point at `v1.11`.