Creating a new release

  1. Ensure that the controller CVE scan action is green.
  2. Go to the releases page and draft a new release.
  3. 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.0.0-beta.3). The release target should be main (the default).
  4. 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.
  5. If publishing an alpha, be sure to mark the release as a pre-release.
  6. 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: git log v2.0.0-beta.3..main.
  7. Publish the release. This will automatically trigger a GitHub action to build and publish an updated Docker image with the latest manager changes.
  8. Ensure that the action associated with your release finishes successfully.
  9. Create a new PR to update our documentation and move resources listed under “Next Release” to the heading “Released” by checking out main, running task and creating a PR of the results.

Cataloging breaking changes in a new release

There may be breaking changes in a new release of ASO, either due to changes we made or changes made in the upstream service Swagger specifications. We must validate each breaking change so that we can notify customers about it.

  1. Download the latest Helm chart release (example beta.3) and extract it.
  2. Run task controller:gen-helm-chart to generate a local helm chart (saved to v2/charts). Extract it as well.
  3. Produce a diff between these files: diff -u <old> <new> > comparison.diff and examine it.

Testing the new release

  1. Create a kind cluster: task controller:kind-create
  2. Install cert-manager: task controller:install-cert-manager
  3. Create the namespace for the operator: k create namespace azureserviceoperator-system
  4. Source the SP credentials to use for the secret and then run task controller:make-sp-secret.
  5. Deploy the operator from MCR: k apply --server-side=true -f https://github.com/Azure/azure-service-operator/releases/download/v2.0.0-beta.3/azureserviceoperator_v2.0.0-beta.3.yaml (We need to use server-side apply because the CRD for VirtualMachines is large enough that it can’t fit in the last-applied-configuration annotation client-side kubectl apply uses.)
  6. Wait for it to start: k get all -n azureserviceoperator-system
  7. 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/v1beta/v1beta20200601_resourcegroup.yaml
k apply -f v2/samples/network/v1beta/v1beta20201101_virtualnetwork.yaml
  8. Make sure they deploy successfully - check in the portal as well.

Creating and testing Helm chart for new release

Note: A PR that does this should be automatically generated when a new release is published. These steps are documented here in case that process fails.

  1. Create a new branch from <NEW_RELEASE_TAG> HEAD
  2. Generate helm manifest for new release: task controller:gen-helm-manifest
  3. Check the version in /v2/charts/azure-service-operator/Chart.yaml if matches with the latest release tag.
  4. Install helm chart: 
    helm install --set azureSubscriptionID=$AZURE_SUBSCRIPTION_ID \
--set azureTenantID=$AZURE_TENANT_ID \
--set azureClientSecret=$AZURE_CLIENT_SECRET \
--set azureClientID=$AZURE_CLIENT_ID \
asov2 -n azureserviceoperator-system --create-namespace ./v2/charts/azure-service-operator/.
  5. Wait for the chart installation.
  6. Wait for it to start: k get all -n azureserviceoperator-system
  7. 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/v1beta/v1beta20200601_resourcegroup.yaml
k apply -f v2/samples/network/v1beta/v1beta20201101_virtualnetwork.yaml
  8. Make sure they deploy successfully - check in the portal as well.
  9. If installed successfully, commit the files under v2/charts/azure-service-operator.
  10. Send a PR.

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.

  1. Delete the release in the releases page.
  2. Delete the tag: git push <origin> --delete <tag>, for example git push origin --delete v2.0.0-alpha.1.

At this point, you can safely publish a “new” release with the same name.