Support for Helm chart dependencies

[paddycarey]

Hi,

Just adding a request for support for Helm chart repositories. I realise you have a full roadmap/workload already, but just wanted to write the request down somewhere.

https://docs.helm.sh/developing_charts/#chart-dependencies

Thanks!

[greysteil]

I'm 👍 on this, and the implementation shouldn't be too tricky (parsing will be trivial, and there's no concept of version conflicts so the update checker should be simple, too).

Thanks for the suggestion!

[mxandeco]

Hi,

Is there any progress on this feature? Is helm support still in the plans?

[greysteil]

Not yet - we have our work cut out with the GitHub integration and the associated increase in scale for Dependabot, but we'd like to get to this (and it's something the community can add, as the relevant addition would be in Dependabot Core.

[varac]

Any progress on this ? I'd really love to use dependabot for helm chart updates as well.

[hazcod]

Interestingly for some stuff I actually track the source repo and parse the version (e.g. out of the go.mod file), but this is not possible with charts. Anyone else an idea for a workaround?

EDIT: I used the same workaround for e.g. kubernetes-dashboard, but it won't work if the Chart is not in its own git repo.
ironpeakservices/infrastructure@bf9b546

[siavashs]

I've started implementing this feature today.

[hazcod]

@siavashs how would that work? Using helmsman?

[siavashs]

@hazcod The logic I'm working on currently:

• The Chart.yaml will be parsed for dependencies. The dependencies will be checked against their respective repository.
• Repositories have an index.yaml which will be fetched and parsed to check for dependency updates.

The above method allows updating dependencies without needing to run any external binaries.

There are other things that I haven't looked into yet:

• Updating Chart.lock (if present) without using helm command.
• Updating archives under charts/
• Supporting provenance.

[siavashs]

I have the initial implementation ready, the only problems are:

• YAML comments cannot be parsed unless I write a custom parser (not gonna happen)
• Dependency list indentation will be lost if they have any indentation

Now regarding the following items:

• Updating Chart.lock (if present) without using helm command.
  This is tricky as helm uses an internal Go package to generate the SHA256 digest (it combines the list of chart dependencies and lock dependencies, etc.)
  It's possible to replicate it in Ruby but they will probably break it in V4, whenever that happens.
  Alternative option is to run helm dep update.
• Updating archives under charts/
  Seems easy to do without running helm but if I decide to go with helm dep update for Chart.lock then no custom implementation is required.
• Supporting provenance.
  Similar to previous item.

Let me know if you have any comments or suggestions. Otherwise expect a PR in coming weeks.

[hazcod]

@siavashs that already seems like a great starting point? Did you open a PR already?
Thank you for your work!

[siavashs]

@hazcod not yet, unfortunately I was too busy.
I'll cleanup the code and open a PR with the initial support for Chart.yaml and then try to implement the rest of the items in future iterations.

[WyriHaximus]

@siavashs In my experience in the past with adding features, the Dependabot team is helpful with this at their own pace.

Also, I'm pretty sure enough of us are interested to have this out there to help out with feedback and core suggestions.

[siavashs]

Checkout the draft PR here: #3031
I'll add tests soon 😄

[WyriHaximus]

• Updating archives under charts/
  Seems easy to do without running helm but if I decide to go with helm dep update for Chart.lock then no custom implementation is required.

Let me know if you have any comments or suggestions. Otherwise expect a PR in coming weeks.

So regarding that specific point, is it only going to update when there are archives under charts/ or also add them when they aren't committed?

[siavashs]

I think dependency archives should be only updated and not added (if possible).

[WyriHaximus]

Yeah I agree, hence asking. Well you have file access so you could compare before and after and only commit archives when existing files updated.

[jurre]

We're currently not adding any new ecosystems, but Helm charts is something we would definitely love to support in the future. The best option if you'd like to build and use this, would be releasing it as a separate gem, using dependabot-core as a dependency and running it on CI (for example using a scheduled GH action).

Once we open up support for new ecosystems again, we could then potentially upstream those changes into dependabot-core.

[mteodori]

consider that most of these updates are paired with tools like helm-docs or terraform-docs that update README files so just updating the manifest is not enough to have a green build

[hazcod]

For those who want to pick up automated dependencies quicker, it seems renovatebot supports helm and more.

[JesperTerkelsen]

It would still be nice to have this feature in dependabot as well.

[alxgomz]

Concrete use-case: The current bitnami mess in bitnami/charts#10539 would be more easily managed with dependabot being able to track charts dependencies

[theaccordance]

It's unfortunate that expansion of ecosystems has been halted, but I understand and appreciate posting the decision. I'm adding my name to the list of people who would like to see this feature request realized, as it would add significant value to keeping up with some off our self-hosted resources that need to stay closer to the latest track.

[niqdev]

Hi, I don't know you, but I can't keep up with the ArgoCD helm chart updates 🤣 ... and I needed a quick, simple, maintainable, and very flexible solution because some of the versions are declared in the values.yaml while other in Chart.yaml, so I ended up writing helm-dependencies-action!

I documented as much as I could in the readme, and this is an example of how to use it

• workflow
• simple dependencies
• dependencies
• sample pr

It's not feature-complete but for now, it does the job! If you have any suggestions or you want to contribute, you are more than welcome! I hope it helps 😊

[onedr0p]

@niqdev

Wouldn't Renovatebot solve this issue as well? It's FOSS, manages a lot of different types of deps and supports Argo including OCI.

[niqdev]

@onedr0p 👀 thanks for the link! It definitely covers way way more and it has nothing to compare! The gist of the action is nothing else than a curl request

curl -sSL "https://artifacthub.io/api/v1/packages/helm/argo/argo-cd/feed/rss" | \
  yq -p=xml '.rss.channel.item[0].title'

5.13.6

and a sed substitution, using jq/yq in whatever file you need, no matter how is the helm chart and covers exclusively yaml files. I suppose for what I need it's more than enough, but I'll definitely look more into it 🙇🏻

[jeffwidman]

Adding some breadcrumbs re: registries for Helm charts:

• GitHub Packages: Helm Chart support (beta) github/roadmap#122
• GitHub Packages: Helm Chart support (GA) github/roadmap#120
• https://github.com/kubernetes/registry.k8s.io 👈 announced fairly recently, we'll see if they eventually support helm charts not just OCI images...

To be clear, no promise of supporting this, just adding breadcrumbs to help keep track of external developments in this ecosystem.

[dgteixeira]

@jurre, any updates on the possible integration of new packages?

[na-jakobs]

@abdulapopoola Any update on this?

[moritzschmitz-oviva]

It's been a while. Are there any updates regarding this feature?

[AlexanderBrevig]

This is a deal breaker for my employer, and we're willing to contribute a PR for supporting open helm repositories.

Would such a PR be accepted?

[timam]

+1 ; willing to contribute

[maxi-bee]

+1; renovate has this already, I would expect less from Dependabot

[kbateman]

+1; would be helpful

[jsayerascb]

+1; would be helpful

[alxgomz]

Let's face it, this issue is opened for more than 6 years and given the looooong track of features being requested and never implemented by GitHub, I have personally lost hope anything would happen.
We have chosen to use Updatecli instead which - imho - is way better and at least properly maintained by someone who DO care about users' feedback.
There are plenty of other solutions as well, but updatecli is the one I know best and feel comfortable recommanding

[abdulapopoola]

This is a deal breaker for my employer, and we're willing to contribute a PR for supporting open helm repositories.

Would such a PR be accepted?

Sorry for the late response, yes, such a contribution will be very welcome.

We do apologize for the lack of responses and we are working hard on becoming more responsive in coming weeks.

Tagging @AlexanderBrevig