Add `helmify` subcommand

[ThorstenHans]

This PR adds the helmify subcommand. Which allows users to generate Helm charts for a Spin App.

The command is added as subcommand to scaffold and re-uses the flags defined on scaffold.

Usage

spin kube scaffold helmify -f ttl.sh/hello-spinkube:24h \
  --memory-request 64Mi \
  --memory-limit 128Mi \
  --cpu-request 100m \
  --cpu-limit 200m \
  --replicas 4

[bacongobbler]

Alternatively, what makes this command different from a starter chart written specifically for Spin apps?

[rajatjindal]

you think it'd make sense to split out helmify as a separate CLI plugin

there is also https://github.com/arttor/helmify (which we use in spin-operator I believe).

[ThorstenHans]

@bacongobbler I was also uncertain if this should be added to kube scaffold or if it should become a custom plugin. Obviously, there are many ways on how to treat k8s deployment manifests.

IMO we could address the majority of scenarios with being able to scaffold plain k8s manifests and helm charts. I went for a subcommand of scaffold because it allowed me to re-use most parts of the CLI interface.

I'm happy to move the command around.

[ThorstenHans]

I don't see a helm starter chart as an equivalent solution for this.

• How could we distribute the starter chart to a broad audience
• Users have to alter the values.yaml and provide all the details of their app

As addition to the 2nd point, spin kube scaffold provides a way more guided experience

[bacongobbler]

While I appreciate your perspective on this matter, I've found @rajatjindal's solution quite compelling. helmify is not only well-regarded within the Helm community, boasting over 1.1k stars on GitHub, but it's also under active development. This signals a robust tool that's gaining traction and is supported by the community.

Through helmify, I was able to generate a Helm chart from the output of spin kube scaffold:

$ spin kube scaffold -f bacongobbler/myapp:1.0.0 | ./helmify mychart
$ cat mychart/templates/myapp.yaml
apiVersion: core.spinoperator.dev/v1alpha1
kind: SpinApp
metadata:
  name: {{ include "mychart.fullname" . }}-myapp
  labels:
  {{- include "mychart.labels" . | nindent 4 }}
spec:
  executor: containerd-shim-spin
  image: bacongobbler/myapp:1.0.0
  replicas: 2

It accepts all of spin kube scaffold's arguments:

><> spin kube scaffold \
    --from bacongobbler/myapp:1.0.0 \
    --autoscaler hpa \
    --cpu-limit 100m \
    --memory-limit 128Mi | ./helmify

This example not only demonstrates the practical utility of helmify, but also its compatibility with spin kube scaffold’s arguments, effectively addressing the specific use case you outlined regarding Helm chart generation for Spin Apps.

I understand the inclination to develop a bespoke solution. However, I would prefer that we harness tools that already exist from the community. It not only fosters collaboration, but also builds upon a foundation of tooling that many developers are already familiar with. Unless there's an overwhelmingly compelling reason to develop something independently, we should strive to engage and collaborate with the community.

Additionally, this project's core objective is to provide a great developer tool to interact with Spin Apps running on Kubernetes. That objective involves the relationship between the Kubernetes API and the client (spin kube). In this context, the necessity of packaging and distribution as Helm charts seems somewhat detached from the project's core objective.

What are your thoughts on documenting the integration of helmify with spin kube scaffold for now, and revisit the need for an alternative solution as we assess community feedback?

[bacongobbler]

Closing; helmify can take spin kube scaffold as input and output a Helm chart.