helmfile VS gitlab

sudo wget https://github.com/helmfile/helmfile/releases/download/v0.159.0/helmfile_0.159.0_linux_amd64.tar.gz sudo tar -xxf helmfile_0.159.0_linux_amd64.tar.gz sudo rm helmfile_0.159.0_linux_amd64.tar.gz sudo mv helmfile /usr/local/bin/

Installation: https://github.com/helmfile/helmfile/releases

What are the benefits over using helmfile? https://helmfile.readthedocs.io/

Helm charts and Helmfile

And now I can just run dudo -l "https://github.com/helmfile/helmfile/releases/download/v{{ version }}/helmfile_{{ version }}_{{ os }}_{{ arch }}.tar.gz" -i /tmp/helmfile.tar.gz -p $HELMFILE_VERSION

I might be misunderstanding your question but we use https://github.com/helmfile/helmfile along with Argo, so essentially between eks and those I could rebuild our entire cluster in minutes.

I am asking which do you choose, Flux or Helmfile. edit: and what criteria do you use to select.

do you publish your own helm chart for your internal services and use it in every environment? if so, you could try to use helmfile within the service's repo itself and store values in a helm/$env directory. then enhance your ci to deploy to dev after the merge/image build phase directly. to try and cut out what sounds like a "deployment/config repo" step you have in the middle that's making everything a pain.

I've used helmfile before to declaratively manage multiple helm charts. It's a higher-level tool, and still uses helm under the hood.

Since the relevant code appears to be in the "ee" directory <https://gitlab.com/gitlab-org/gitlab/-/blob/v16.11.0-ee/ee/l...> and is not present in the foss repo, I'm guessing the answer is no, at least for now. They do have a history of "releasing" features from EE back to CE but my suspicion is not for LLM stuff

(Side note: Issues are usually hash-prefixed like #1234 both on GitLab and GitHub. However, commit messages must not begin with a hash, they would be considered a comment and ignored. Therefore, GitHub has introduced the alternative prefix GH- and I've contributed a similar prefix GL- to GitLab a while ago.)

and its "oh, you want multi-arch, do you?" friend. While prosecuting this <https://gitlab.com/gitlab-org/gitlab/-/issues/339567> I learned that https://hub.docker.com/layers/multiarch/qemu-user-static/7.2... actually mutates the binfmt_misc in buildx's context in order to exec the static copy of qemu in it https://github.com/multiarch/qemu-user-static/blob/v7.2.0-1/...

and, that the buildx plugin itself has some qemu magick in it, which got addressed in a minor version bump but I couldn't track down the relevant GitHub issue this second (I've flushed it from my mind, only recalling that there were a lot of actors in that tire fire)

This is actually a follow-up refactor, the fix is here: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...