Should we switch to go or Ruby ?

added meta label

Are there significant advantages to using the helm packages directly?
Are there other golang features or libraries we think we could benefit from?

Given that auto-deploy-image is still pretty simple, maybe we should just try porting it to golang as an exercise?

Are there significant advantages to using the helm packages directly?

There's a native go helm client library (I think it's actually what helm uses internally) https://godoc.org/k8s.io/helm/pkg/helm#NewClient - Although I suspect, using either ruby or go, that we'll end up still executing helm commands directly for backwards compat. E.g. HELM_UPGRADE_EXTRA_ARGS

There'll likely be big breaking changes to these libs when helm3 comes out.

Are there other golang features or libraries we think we could benefit from?

Kubernetes has a client lib too https://github.com/kubernetes/client-go. It's quite nice having all the client APIs strongly typed - especially for upgrades where refactoring is required. Another small benefit to go is you can likely make a smaller docker image.

I'm wondering if this is worth doing at all until we have some planned features that might require the extra complexity. There are some nice things we'll get by doing this, like presumably having real unit tests is a benefit and maybe being able to handle environment variables slightly nicer, but I think there are some downsides too. For example, if we move away from bash could we expect as many community contributions? Are we sure that auto-deploy-image + auto-deploy-app is the best architecture for deploys (we already have a tool to deploy knative apps, gitlabktl, what about extending that? or what about operators? deploying operators is typically just applying a manifest).

In my opinion the most complicated part of the deploys is the helm chart, auto-deploy-app, I think this would have the biggest benefit to a rewrite with proper testing. That's probably off topic though