Split the helm chart into a new repo or Equate the the Helm chart version with the pod-reaper version

[rogerioefonseca]

Hello, I'm configuring the pod-reaper helm chart with Renovate bot, then I figured that the helm chart version is not the same as the pod-reaper code.
For that there are 2 strategies that I can see now:
1 - Separate the Helm chart code in a new repo and maintain it there (That would be a better OMHO)
2 - Equate the Helm Chart version to match the pod-reaper version so then I could create a new MR with a real tagging version.

[brianberzins]

I actually don't know much about helm...

I see a couple of things like this:

pod-reaper/chart/pod-reaper/values.yaml

Line 6 in 9b4221d

tag: 2.8.0

pod-reaper/chart/pod-reaper/Chart.yaml

Line 4 in 9b4221d

version: 0.1.0

Seems like both of those are candidates for matching up with the pod-reaper version correct?
Is there a repository where new versions are updated? How is it being used right now?

[brianberzins]

Trying to ask this a different way. With charts also being versioned, are the charts published anywhere (or are they someone pulled directly from github/here)? Trying to see if/when these have been published.

I've got a lot to learn here!

[rogerioefonseca]

Nice, so regarding that, the strategy that is most common to opensource projects is to create a separate repo only for the helm files, create the helm package and add it to the repo as well and then integrate that repo with the CNCF project https://artifacthub.io/.
After that we will be able to install the helm charts using only the helm repo add and helm install pod-reaper --version XYZ

I can see those steps ahead.

• Create a new repo and on that, include only the helm yaml files and needs.
• Create the new stable helm package with
  - [ ] Create the structure like mkdir stable && helm package . -d stable/
  - [ ] Create the helm package helm package . -d stable/
• Enable the github pages in the repository properties
• Create an account in artifacthub.io, create a new repo and integrate that with the GitHub pod-reaper github Page

Let me know if I can help somehow.

[rogerioefonseca]

Hey, I took the liberty to execute the steps above, but I would only use it if you agree, and then I would transfer the ownership to you.
https://github.com/rogerioefonseca/pod-reaper-helm
https://artifacthub.io/packages/helm/pod-reaper-chart/pod-reaper

[brianberzins]

Only managed to find a bit of time to dig at this...

What's the advantage of having a separate repository for just the chart? Doesn't that mean keeping both in sync?
Mostly just trying to understand and I suspect that is in part because of how long I've used the pattern of "just have full kubernetes manifest files live in my application's repository, fully codifying the app, deployment configuration, and pipeline together in the same repo".

[rogerioefonseca]

So that is a nice question and my points are pretty much related to your comment when you mention the "just have full kubernetes manifest files live in my application's repository, fully codifying the app, deployment configuration, and pipeline together in the same repo". :)
Helm Charts have its only responsibility and it is more related to Kubernetes rather than your application, having the Helm charts in a separate repo would:
Pros:

• Make the repository cleaner easy to read(and it is not everyone that needs or knows how to deal with Helm).
• Helm Charts depend on Helm versions and having it in a reparate repo would make it easier to release/tag it.
• As it is an open-source project it would be easier to have the community contributing to it in a direct way.
• We would be using the pattern that CNCF is using, so it would be kind of a "Certificate of good practice"(https://codefresh.io/docs/docs/new-helm/helm-best-practices/)
• Maybe in the future, we could think of running the pod-reaper in an AWS lambda function or an ECS Cloud formation code as well, and then we would have to increment the folder structure.

Cons:

• If you have to change something that affects the helm you would need to create 2 MR's, one for each repo
• Deal with different pipelines and related resources

[rogerioefonseca]

Ping!
Happy new year!!

[brianberzins]

I'm currently leaning towards trying to do it in this repo, but mostly because it means fewer PRs, makes it easier to automate between release of the helm chart and the code. Also because I'm not an owner/admin of the Target organization, so I'd have to have someone else make it (unless I want to do it under my personal space).

[rogerioefonseca]

Yep, fair enough, I still did not understand the fewer PR's that you mentioned since the Helm charts are not really being changed that much.
Can you please keep the Helm version the same as the repo? :)

[brianberzins]

Oh, maybe my understanding is wrong... wouldn't I want to update the helm chart to use the latest version of the pod-reaper in the helm chart each time I update the pod-reaper?

I'm mostly thinking about this version number:

pod-reaper/chart/pod-reaper/values.yaml

Line 6 in 9b4221d

tag: 2.8.0

[rogerioefonseca]

No it is not that one.
The chart version should match the TAG version -

pod-reaper/chart/pod-reaper/Chart.yaml

Line 4 in 9b4221d

version: 0.1.0

[rogerioefonseca]

Ping...

[brianberzins]

Thanks for the ping. I'm mostly just swamped with work this week. I promise it's still on my to-do list

Is there a date you'd really like to see this by? Or just as ASAP thing?

In either case, honestly appreciate the reminders!

[rogerioefonseca]

haha, for me it would be an ASAP thing, haha.
:)

[brianberzins]

@rogerioefonseca
Way too much I'm not tracking with helm.
Any chance you'd be up for a pair programming session sometime?
I think there are a few things needed to make this work that'd be overstepping my bounds as I'm not an admin on this repo. So I'm considering doing this all myself on a git repo (very similar to what you had), but I'd like to know more about expected use cases.

When this is all working properly, what are some examples of commands you want to see working?