Feature Suggestion - Repackaging for Helm Charts

Stephen.Schaff

I am currently building out my CI/CD pipeline for Kubernetes. One of the things I am currently doing is making a process to repackage a prerelease Helm Chart as a release version and promote it to a release feed. To accomplish that, I am doing this:

Download a Helm Chart
Update its version numbers (a Helm Chart has 2 version numbers), and Image Tag (which for me is the same as the version number.) Basically, I am converting the version numbers from pre-release (ie 2.0.3-build.12) to release version numbers (ie 2.0.3)
Upload the chart into a new feed.

As I was working on that, I noticed an Repackaging API. Looking into it, it seems it is very similar to what I am doing, but it is intended for NuGet and universal feeds only.

This is not a "Feature Request" (because even if you made it, I will not need it by the time you get done). But I thought I would throw it out there as a possible suggestion to add value to ProGet. (The only real concern I could see is if the packages were signed, then you would need access to the Key to re-sign them.)

stevedennis

Hey @Stephen-Schaff ,

We'd love to expand repackaging to more feed types! It's still a pretty new concepts, and not too many folks understand the value of the process/feature.

The main thing that ProGet adds is the audit-trail -- basically metadata added to do the package itself, so the "history" lives with it. Plus this way, you don't have to reproduce that download/repack/reupload process over and over again.

Any suggestions on where to add this to the chart? I think we just inject a basic file in the NuGet package, maybe that would work in Helm as well?

Cheers
Steve

Stephen.Schaff

I think you can just add a file to the chart at the root level. But I am not a helm expert, so take my opinion with a grain of salt.

I am going to be doing some helm testing soon(ish). I will try to add in a random file and see if Helm/Kubernetes just ignores it when I do an install.

stevedennis

@Stephen-Schaff let us know! If that works, then we can just inject that in the package, and read it in on the history page, similar to this NuGet package:

https://proget.inedo.com/feeds/NuGetLibraries/Inedo.ExecutionEngine/100.1.1/history