Improve testing with a kind cluster

Taskfile.yml

@@ -929,6 +929,10 @@ tasks:
             {{.SCRIPTS_ROOT}}/kind-with-registry.sh"
     status:
       - "kind get clusters | grep \"^asov2-wi$\""
+    preconditions:
+      # If our working directory starts with /workspaces then we're running in a container and need HOSTROOT to be defined
+      - sh: '[ "${PWD#/workspaces}" = "$PWD" ] || [ -n "${HOSTROOT-}" ]'
+        msg: "When running in a container (detected via PWD starting with /workspaces) you must set HOSTROOT to the host's root path so that files can be mounted into kind clusters correctly."
     env:
       SERVICE_ACCOUNT_KEY_FILE:
         sh: "echo ${HOSTROOT:-$PWD}/{{.KIND_WORKLOAD_IDENTITY_PATH}}/sa.pub" # Have to use HOSTROOT here for mounting files when in docker-in-docker as paths are relative to host

docs/hugo/content/contributing/create-a-new-release.md

@@ -8,7 +8,7 @@ title: Creating a new release
 4. Go to the [releases](https://github.com/Azure/azure-service-operator/releases) page and draft a new release.
 5. In the tag dropdown, type the name of the new tag you'd like to create (it should match the pattern of previous releases tags, for example: `v2.10.0`). The release target should be `main` (the default).
 6. Use the GitHub "auto-generate release notes" button to generate a set of release notes to work with. You will need to clean this up quite a bit before actually publishing it.
-7. Write a "Release Notes" section. You can edit the autogenerated section as a start. You can also look through the commits between the last release and now: 
+7. Write a "Release Notes" section. You can edit the autogenerated section as a start. You can also look through the commits between the last release and now:
 
    ``` bash
    git log v2.4.0..main
@@ -54,33 +54,38 @@ Perform a simple smoke test to make sure the new release is capable of starting
    * AZURE_TENANT_ID
 
 2. Create a kind cluster
+
    ``` bash
    task controller:kind-create-wi
    ```
 
 3. Enable workload identity on that cluster:
-   ```
+
+   ``` bash
    task controller:create-mi-for-workload-identity
    ```
 
 4. Install cert-manager
+
    ``` bash
    task controller:install-cert-manager
    ```
 
 5. Create the namespace for the operator
+
    ``` bash
    kubectl create namespace azureserviceoperator-system
    ```
 
 6. Create a secret in your cluster with the Workload Identity credentials for ASO to use:
+
    ``` bash
    task controller:make-workload-identity-secret
    ```
 
 7. Download asoctl
 
-   ``` bash 
+   ``` bash
    curl -L https://github.com/Azure/azure-service-operator/releases/latest/download/asoctl-linux-amd64.gz -o asoctl.gz
    gunzip asoctl.gz
    chmod +x asoctl
@@ -93,6 +98,7 @@ Perform a simple smoke test to make sure the new release is capable of starting
    ```
 
 9. Watch while ASO starts
+
    ``` bash
    kubectl get all -n azureserviceoperator-system
    ```
@@ -103,6 +109,7 @@ Perform a simple smoke test to make sure the new release is capable of starting
     kubectl apply -f v2/samples/resources/v1api/v1api20200601_resourcegroup.yaml
     kubectl apply -f v2/samples/network/v1api20240301/v1api20240301_virtualnetwork.yaml
     ```
+
 11. Make sure they deploy successfully - check in the portal as well.
 
 ## Create and test the Helm chart
@@ -121,15 +128,19 @@ These steps are documented here in case that process fails.
 ### Test the updated chart
 
 1. Create a kind cluster with the chart installed
+
    ``` bash
    task controller:kind-create-workloadidentity-local-helm
    ```
+
 2. Wait for it all to start: `k get all -n azureserviceoperator-system`
 3. Create a resource group and a vnet in it (the vnet is to check that conversion webhooks are working, since there aren't any for RGs):
+
     ```
     k apply -f v2/samples/resources/v1api/v1api20200601_resourcegroup.yaml
     k apply -f v2/samples/network/v1api20201101/v1api20201101_virtualnetwork.yaml
     ```
+
 4. Make sure they deploy successfully - check in the portal as well.
 5. If installed successfully, commit the files under `v2/charts/azure-service-operator`.
 6. Send a PR.
@@ -139,7 +150,7 @@ These steps are documented here in case that process fails.
 Any resources included in the new release will currently be listed under "Next Release" in the documentation, so we need to update the documentation to move them to the "Released" section.
 
 1. Create a new branch from `main` and check it out.
-2. Update the setting `supportedResourcesReport.currentRelease` to the new release in `v2/azure-arm.yaml` 
+2. Update the setting `supportedResourcesReport.currentRelease` to the new release in `v2/azure-arm.yaml`
 3. Run `task controller:generate-types` to update the documentation.
 4. Repeat the above steps by modifying `hack/crossplane/azure-crossplane.yml` and running `task crossplane:generate-types`.
 5. Commit the changes and send a PR.
@@ -160,8 +171,8 @@ If you earlier [catalogued breaking changes](#catalog-breaking-changes), or if t
 
 ## Fixing an incorrect release
 
-If there was an issue publishing a new release, we may want to delete the existing release and try again. 
-Only do this if you've just published the release and there is something wrong with it. We shouldn't be deleting releases people are actually using. 
+If there was an issue publishing a new release, we may want to delete the existing release and try again.
+Only do this if you've just published the release and there is something wrong with it. We shouldn't be deleting releases people are actually using.
 
 1. Delete the release in the [releases](https://github.com/Azure/azure-service-operator/releases) page.
 2. Delete the tag: `git push <origin> --delete <tag>`, for example `git push origin --delete v2.0.0-alpha.1`.