chore(chart): Updated release logic to use SemVer

Signed-off-by: Steve Hipwell <[email protected]>

Makefile

@@ -145,7 +145,7 @@ apply: image ## Deploy the controller from the current state of your git reposit
 
 install:  ## Deploy the latest released version into your ~/.kube/config cluster
 	@echo Upgrading to ${KARPENTER_VERSION}
-	helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version ${KARPENTER_VERSION} --namespace ${KARPENTER_NAMESPACE} \
+	helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter --version ${KARPENTER_VERSION#v} --namespace ${KARPENTER_NAMESPACE} \
 		$(HELM_OPTS)
 
 delete: ## Delete the controller from your ~/.kube/config cluster

charts/karpenter/Chart.yaml

@@ -13,4 +13,22 @@ keywords:
 home: https://karpenter.sh/
 icon: https://repository-images.githubusercontent.com/278480393/dab059c8-caa1-4b55-aaa7-3d30e47a5616
 sources:
-  - https://github.com/aws/karpenter/
+  - https://github.com/aws/karpenter-provider-aws/
+annotations:
+  artifacthub.io/alternativeName: karpenter-provider-aws
+  artifacthub.io/crds: |
+    - kind: EC2NodeClass
+      version: v1beta1
+      name: ec2nodeclasses.karpenter.k8s.aws
+      displayName: EC2NodeClass
+      description: EC2NodeClass is the Schema for the EC2NodeClass API.
+    - kind: NodeClaim
+      version: v1beta1
+      name: nodeclaims.karpenter.sh
+      displayName: NodeClaim
+      description: NodeClaim is the Schema for the NodeClaims API.
+    - kind: NodePool
+      version: v1beta1
+      name: nodepools.karpenter.sh
+      displayName: NodePool
+      description: NodePool is the Schema for the NodePools API.

hack/release/common.sh

@@ -97,11 +97,11 @@ releaseType(){
 helmChartVersion(){
     RELEASE_VERSION=$1
     if [[ $(releaseType "$RELEASE_VERSION") == "$RELEASE_TYPE_STABLE" ]]; then
-      echo "$RELEASE_VERSION"
+      echo "${RELEASE_VERSION#v}"
     fi
 
     if [[ $(releaseType "$RELEASE_VERSION") == "$RELEASE_TYPE_SNAPSHOT" ]]; then
-      echo "v${CURRENT_MAJOR_VERSION}-${RELEASE_VERSION}"
+      echo "${CURRENT_MAJOR_VERSION}-${RELEASE_VERSION}"
     fi
 }
 
@@ -127,13 +127,15 @@ publishHelmChart() {
     RELEASE_REPO=$3
     HELM_CHART_VERSION=$(helmChartVersion "$RELEASE_VERSION")
     HELM_CHART_FILE_NAME="${CHART_NAME}-${HELM_CHART_VERSION}.tgz"
+    AH_CONFIG_FILE_NAME="${CHART_NAME}/artifacthub-repo.yaml"
 
     cd charts
     helm dependency update "${CHART_NAME}"
     helm lint "${CHART_NAME}"
     helm package "${CHART_NAME}" --version "$HELM_CHART_VERSION"
     helm push "${HELM_CHART_FILE_NAME}" "oci://${RELEASE_REPO}"
     rm "${HELM_CHART_FILE_NAME}"
+    [[ -s "${AH_CONFIG_FILE_NAME}" ]] && oras push "${RELEASE_REPO}:artifacthub.io" --config /dev/null:application/vnd.cncf.artifacthub.config.v1+yaml "${AH_CONFIG_FILE_NAME}:application/vnd.cncf.artifacthub.repository-metadata.layer.v1.yaml"
     cd ..
 }
 

hack/toolchain.sh

@@ -23,6 +23,7 @@ tools() {
     go install github.com/onsi/ginkgo/v2/ginkgo@latest
     go install github.com/rhysd/actionlint/cmd/actionlint@latest
     go install github.com/mattn/goveralls@latest
+    go install oras.land/oras/cmd/oras@latest
 
     if ! echo "$PATH" | grep -q "${GOPATH:-undefined}/bin\|$HOME/go/bin"; then
         echo "Go workspace's \"bin\" directory is not in PATH. Run 'export PATH=\"\$PATH:\${GOPATH:-\$HOME/go}/bin\"'."

website/content/en/preview/contributing/development-guide.md

@@ -73,7 +73,8 @@ make test       # E2E correctness tests
 
 ### Change Log Level
 
-By default, `make apply` will set the log level to debug. You can change the log level by setting the log level in your helm values. 
+By default, `make apply` will set the log level to debug. You can change the log level by setting the log level in your Helm values.
+
 ```bash
 --set logLevel=debug
 ```

website/content/en/preview/faq.md

@@ -26,7 +26,7 @@ Karpenter has multiple mechanisms for configuring the [operating system]({{< ref
 Karpenter is flexible to multi-architecture configurations using [well known labels]({{< ref "./concepts/scheduling/#supported-labels">}}).
 
 ### What RBAC access is required?
-All the required RBAC rules can be found in the helm chart template. See [clusterrole-core.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/clusterrole-core.yaml), [clusterrole.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/clusterrole.yaml), [rolebinding.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/rolebinding.yaml), and [role.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/role.yaml) files for details.
+All the required RBAC rules can be found in the Helm chart template. See [clusterrole-core.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/clusterrole-core.yaml), [clusterrole.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/clusterrole.yaml), [rolebinding.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/rolebinding.yaml), and [role.yaml](https://github.com/aws/karpenter/blob{{< githubRelRef >}}charts/karpenter/templates/role.yaml) files for details.
 
 ### Can I run Karpenter outside of a Kubernetes cluster?
 Yes, as long as the controller has network and IAM/RBAC access to the Kubernetes API and your provider API.
@@ -202,7 +202,7 @@ Use your existing upgrade mechanisms to upgrade your core add-ons in Kubernetes
 
 Karpenter requires proper permissions in the `KarpenterNode IAM Role` and the `KarpenterController IAM Role`.
 To upgrade Karpenter to version `$VERSION`, make sure that the `KarpenterNode IAM Role` and the `KarpenterController IAM Role` have the right permission described in `https://karpenter.sh/$VERSION/getting-started/getting-started-with-karpenter/cloudformation.yaml`.
-Next, locate `KarpenterController IAM Role` ARN (i.e., ARN of the resource created in [Create the KarpenterController IAM Role](../getting-started/getting-started-with-karpenter/#create-the-karpentercontroller-iam-role)) and pass them to the helm upgrade command.
+Next, locate `KarpenterController IAM Role` ARN (i.e., ARN of the resource created in [Create the KarpenterController IAM Role](../getting-started/getting-started-with-karpenter/#create-the-karpentercontroller-iam-role)) and pass them to the Helm upgrade command.
 {{% script file="./content/en/{VERSION}/getting-started/getting-started-with-karpenter/scripts/step08-apply-helm-chart.sh" language="bash"%}}
 
 For information on upgrading Karpenter, see the [Upgrade Guide]({{< ref "./upgrading/upgrade-guide/" >}}).

website/content/en/preview/getting-started/getting-started-with-karpenter/_index.md

@@ -44,9 +44,9 @@ authenticate properly by running `aws sts get-caller-identity`.
 After setting up the tools, set the Karpenter and Kubernetes version:
 
 ```bash
-export KARPENTER_NAMESPACE=kube-system
-export KARPENTER_VERSION=v0.33.1
-export K8S_VERSION={{< param "latest_k8s_version" >}}
+export KARPENTER_NAMESPACE="kube-system"
+export KARPENTER_VERSION="v0.33.1"
+export K8S_VERSION="{{< param "latest_k8s_version" >}}"
 ```
 
 Then set the following environment variable:
@@ -75,7 +75,7 @@ The following cluster configuration will:
 * Use [AWS EKS managed node groups](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) for the kube-system and karpenter namespaces. Uncomment fargateProfiles settings (and comment out managedNodeGroups settings) to use Fargate for both namespaces instead.
 * Set KARPENTER_IAM_ROLE_ARN variables.
 * Create a role to allow spot instances.
-* Run helm to install karpenter
+* Run Helm to install Karpenter
 
 {{% script file="./content/en/{VERSION}/getting-started/getting-started-with-karpenter/scripts/step02-create-cluster.sh" language="bash"%}}
 
@@ -97,11 +97,11 @@ If you need Karpenter to manage the DNS service pods' capacity, this means that
 {{% /alert %}}
 
 {{% alert title="Common Expression Language/Webhooks Notice" color="warning" %}}
-Karpenter supports using [Kubernetes Common Expression Language](https://kubernetes.io/docs/reference/using-api/cel/) for validating its Custom Resource Definitions out-of-the-box; however, this feature is not supported on versions of Kubernetes < 1.25. If you are running an earlier version of Kubernetes, you will need to use the Karpenter admission webhooks for validation instead. You can enable these webhooks with `--set webhook.enabled=true` when applying the Karpenter helm chart.
+Karpenter supports using [Kubernetes Common Expression Language](https://kubernetes.io/docs/reference/using-api/cel/) for validating its Custom Resource Definitions out-of-the-box; however, this feature is not supported on versions of Kubernetes < 1.25. If you are running an earlier version of Kubernetes, you will need to use the Karpenter admission webhooks for validation instead. You can enable these webhooks with `--set webhook.enabled=true` when applying the Karpenter Helm chart.
 {{% /alert %}}
 
 {{% alert title="Pod Identity Supports Notice" color="warning" %}}
-Karpenter now supports using [Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) to authenticate AWS SDK to make API requests to AWS services using AWS Identity and Access Management (IAM) permissions. This feature not supported on versions of Kubernetes < 1.24.  If you are running an earlier version of Kubernetes, you will need to use the [IAM Roles for Service Accounts(IRSA)](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html) for pod authentication instead. You can enable these IRSA with `--set "serviceAccount.annotations.eks\.amazonaws\.com/role-arn=${KARPENTER_IAM_ROLE_ARN}"` when applying the Karpenter helm chart.
+Karpenter now supports using [Pod Identity](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) to authenticate AWS SDK to make API requests to AWS services using AWS Identity and Access Management (IAM) permissions. This feature not supported on versions of Kubernetes < 1.24.  If you are running an earlier version of Kubernetes, you will need to use the [IAM Roles for Service Accounts(IRSA)](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html) for pod authentication instead. You can enable these IRSA with `--set "serviceAccount.annotations.eks\.amazonaws\.com/role-arn=${KARPENTER_IAM_ROLE_ARN}"` when applying the Karpenter Helm chart.
 {{% /alert %}}
 
 {{% alert title="Warning" color="warning" %}}
@@ -177,7 +177,7 @@ The section below covers advanced installation techniques for installing Karpent
 
 ### Private Clusters
 
-You can optionally install Karpenter on a [private cluster](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html#private-cluster-requirements) using the `eksctl` installation by setting `privateCluster.enabled` to true in your [ClusterConfig](https://eksctl.io/usage/eks-private-cluster/#eks-fully-private-cluster) and by setting `--set settings.isolatedVPC=true` when installing the `karpenter` helm chart.
+You can optionally install Karpenter on a [private cluster](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html#private-cluster-requirements) using the `eksctl` installation by setting `privateCluster.enabled` to true in your [ClusterConfig](https://eksctl.io/usage/eks-private-cluster/#eks-fully-private-cluster) and by setting `--set settings.isolatedVPC=true` when installing the `karpenter` Helm chart.
 
 ```bash
 privateCluster:

website/content/en/preview/getting-started/migrating-from-cas/_index.md

@@ -92,10 +92,10 @@ One for your Karpenter node role and one for your existing node group.
 First set the Karpenter release you want to deploy.
 
 ```bash
-export KARPENTER_VERSION={{< param "latest_release_version" >}}
+export KARPENTER_VERSION="{{< param "latest_release_version" >}}"
 ```
 
-We can now generate a full Karpenter deployment yaml from the helm chart.
+We can now generate a full Karpenter deployment yaml from the Helm chart.
 
 {{% script file="./content/en/{VERSION}/getting-started/migrating-from-cas/scripts/step08-generate-chart.sh" language="bash" %}}
 

website/content/en/preview/getting-started/migrating-from-cas/scripts/step08-generate-chart.sh

@@ -1,4 +1,4 @@
-helm template karpenter oci://public.ecr.aws/karpenter/karpenter --version "${KARPENTER_VERSION}" --namespace "${KARPENTER_NAMESPACE}" \
+helm template karpenter oci://public.ecr.aws/karpenter/karpenter --version "${KARPENTER_VERSION#v}" --namespace "${KARPENTER_NAMESPACE}" \
     --set "settings.clusterName=${CLUSTER_NAME}" \
     --set "serviceAccount.annotations.eks\.amazonaws\.com/role-arn=arn:${AWS_PARTITION}:iam::${AWS_ACCOUNT_ID}:role/KarpenterControllerRole-${CLUSTER_NAME}" \
     --set controller.resources.requests.cpu=1 \

website/content/en/preview/reference/cloudformation.md

@@ -17,7 +17,7 @@ These descriptions should allow you to understand:
 To download a particular version of `cloudformation.yaml`, set the version and use `curl` to pull the file to your local system:
 
 ```bash
-export KARPENTER_VERSION={{< param "latest_release_version" >}}
+export KARPENTER_VERSION="{{< param "latest_release_version" >}}"
 curl https://raw.githubusercontent.com/aws/karpenter-provider-aws/"${KARPENTER_VERSION}"/website/content/en/preview/getting-started/getting-started-with-karpenter/cloudformation.yaml > cloudformation.yaml
 ```
 

website/content/en/preview/troubleshooting.md

@@ -29,7 +29,7 @@ Update the zap-logger-config "level" and restart the Karpenter pod(s) to enable
 
 #### Debug logging via Helm
 
-You can enable debug logging during installation with helm by setting the option `logLevel`.
+You can enable debug logging during installation with Helm by setting the option `logLevel`.
 
 ```
 helm upgrade --install karpenter oci://public.ecr.aws/karpenter/karpenter \
@@ -89,18 +89,18 @@ To do so on AWS increase the `minimum` and `desired` parameters on the node grou
 
 ### Helm Error When Pulling the Chart
 
-If Helm is showing an error when trying to install Karpenter helm charts:
+If Helm is showing an error when trying to install Karpenter Helm charts:
 
 - Ensure you are using a newer Helm version, Helm started supporting OCI images since v3.8.0.
 - Helm does not have an `helm repo add` concept in OCI, so to install Karpenter you no longer need this
 - Verify that the image you are trying to pull actually exists in [gallery.ecr.aws/karpenter](https://gallery.ecr.aws/karpenter/karpenter)
-- Sometimes Helm generates a generic error, you can add the --debug switch to any of the helm commands in this doc for more verbose error messages
+- Sometimes Helm generates a generic error, you can add the --debug switch to any of the Helm commands in this doc for more verbose error messages
 - If you are getting a 403 forbidden error, you can try `docker logout public.ecr.aws` as explained [here](https://docs.aws.amazon.com/AmazonECR/latest/public/public-troubleshooting.html)
-- If you are receiving this error: `Error: failed to download "oci://public.ecr.aws/karpenter/karpenter" at version "0.17.0"`, then you need to prepend a `v` to the version number: `v0.17.0`. Before Karpenter moved to OCI helm charts (pre-v0.17.0), both `v0.16.0` and `0.16.0` would work, but OCI charts require an exact version match.
+- If you are receiving this error: `Error: failed to download "oci://public.ecr.aws/karpenter/karpenter" at version "0.17.0"`, then you need to prepend a `v` to the version number: `v0.17.0`. Before Karpenter moved to OCI Helm charts (pre-v0.17.0), both `v0.16.0` and `0.16.0` would work, but OCI charts require an exact version match.
 
 ### Helm Error when installing the `karpenter-crd` chart
 
-Karpenter v0.26.1+ introduced the `karpenter-crd` helm chart. When installing this chart on your cluster, if you have previously added the Karpenter CRDs to your cluster through the `karpenter` controller chart or through `kubectl replace`, Helm will reject the install of the chart due to `invalid ownership metadata`.
+Karpenter v0.26.1+ introduced the `karpenter-crd` Helm chart. When installing this chart on your cluster, if you have previously added the Karpenter CRDs to your cluster through the `karpenter` controller chart or through `kubectl replace`, Helm will reject the install of the chart due to `invalid ownership metadata`.
 
 - In the case of `invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"` run:
 

website/content/en/preview/upgrading/compatibility.md

@@ -31,7 +31,7 @@ For more information on Karpenter's support for these keys, view [this tracking
 {{% /alert %}}
 
 {{% alert title="Note" color="warning" %}}
-Karpenter supports using [Kubernetes Common Expression Language](https://kubernetes.io/docs/reference/using-api/cel/) for validating its Custom Resource Definitions out-of-the-box; however, this feature is not supported on versions of Kubernetes < 1.25. If you are running an earlier version of Kubernetes, you will need to use the Karpenter admission webhooks for validation instead. You can enable these webhooks with `--set webhook.enabled=true` when applying the Karpenter helm chart.
+Karpenter supports using [Kubernetes Common Expression Language](https://kubernetes.io/docs/reference/using-api/cel/) for validating its Custom Resource Definitions out-of-the-box; however, this feature is not supported on versions of Kubernetes < 1.25. If you are running an earlier version of Kubernetes, you will need to use the Karpenter admission webhooks for validation instead. You can enable these webhooks with `--set webhook.enabled=true` when applying the Karpenter Helm chart.
 {{% /alert %}}
 
 ## Compatibility issues