GitVersion VS kubernetes-external-secrets

Gitversion: It reads your commit history and generates a semver version out of it. Say you are compiling main branch and have a tag 1.0. Then, you squash 3 PRs. When you build this version, the new version number will be 1.0.3. You can configure it to be smarter about increasing major, minor, patch fields. I typically use prefix on the commit messages so that it generates versions correctly. See more at https://gitversion.net/docs/

GitVersion is not available by default and needs to be installed beforehand if we want to use the features it offers. The action is available here.

Check this out https://gitversion.net/docs/

At work we use https://gitversion.net/docs/ in our devops pipelines. Similaf to git-semver it generates a version based on what's published previously.

Under Linux I use gitflow and gitversion. The former helps me with branch and tags management, the latter keep tracks of the semantic version in a semi-automatic fashion (given a branch/commit/tag it generate a semver automatically based on the repo log). Gitflow should be supported by GUI tools too, but I'm more a CLI guy.

I’m not sure about in Bitbucket, but our pipeline has installed GitVersion which ups the build version based on SemVer. https://gitversion.net/docs/ We have a HealthCheck endpoint to return this version.

I know that GitVersion exists, which I think can automatically calculate the version number for me. But it's not entirely clear to me that it will do this. Also it doesn't seem to have a nbgv set-version equivalent that will just create a tag based on the calculated version number.

Kind of like you mention though, I tend to still create a build script using gitversion then just have the GitHub Action kick off the script. I find value in being able to create artifacts on a developer machine so having a simple script to run makes that as painless as possible and when I last looked a year or so ago there wasn't a good way of running GitHub Actions on your development machine.

Self promotion: I made Verlite for this purpose, tho something like GitVersion might be more suitable for your workflow.

$ helm repo add external-secrets https://external-secrets.github.io/kubernetes-external-secrets/ "external-secrets" has been added to your repositories $ helm install k8s-external-secrets external-secrets/kubernetes-external-secrets -f values.yaml NAME: k8s-external-secrets LAST DEPLOYED: Wed Mar 23 22:50:35 2022 NAMESPACE: default STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: The kubernetes external secrets has been installed. Check its status by running: $ kubectl --namespace default get pods -l "app.kubernetes.io/name=kubernetes-external-secrets,app.kubernetes.io/instance=k8s-external-secrets" Visit https://github.com/external-secrets/kubernetes-external-secrets for instructions on how to use kubernetes external secrets

I’m reading above that you weren’t aware of sealed-secrets. So I guess that you are not familiar with ExternalSecrets secrets neither. Very solid project

They probably should merge with https://github.com/external-secrets/kubernetes-external-secr...

I do not recommend vault if you are not experienced. It is a heavy infra to manage. I suggest looking into https://github.com/external-secrets/kubernetes-external-secrets and selecting the tool offered by your cloud providers.

This is where things like the vault agent sidecar or projects like external secrets come in and allow you to inject / sync your secrets backend and your Kubernetes workloads :)

Depending on what platform you are on, you could use the AWS SDK or a tool like external-secrets (for Kubernetes).

We don't keep anything sensitive inside of Helm charts. We use AWS Secrets Manager and external-secrets