I am trying to use Helm upgrade step from Octopus Deploy. I want to use your step to upgrade/install helm chart. As you know more of Helm Charts contains default values as YAML file. This is very weird, because in some step process I can enable Structured configuration variables, which can replace variables based on Variables defined in Project. In this case I cannot to do this.
As workaround I tried to build my process from two steps. First with Bash script step, where I wanted to download Chart from feed. Replace variables by Structured configuration variables and save file content with this - Output variables - Octopus Deploy. Then in second step - Helm upgrade step, I wanted to use output from first step and pass It as Raw YAML file in Helm upgrade step. But this also not work. Octopus raise a error, when I define helm referenced package in step process different than Helm upgrade. Looks like helm feed works with Helm upgrade step only.
Now, I can define variables on Project level, but then I need to defined them in process. Any changes in process force to create new release.
Do you have plans to enable structured configuration variables for Helm step ? Maybe you have any other idea how to achieve this ?
PS. In my opinion Octopus should have a feature, that allow generate YAML, JSON, properties file from project variables without any placeholders.
Thanks for getting in touch! Great question, and I appreciate your suggestion to get this feature added into the Helm step. I have seen discussion previously about the desire to add it in, however I don’t believe it’s a super high priority piece of work at the moment unfortunately. I spotted it suggested in our public UserVoice site, so it’d be worth throwing some votes to.
When doing some searching on how others have addressed this, I came across this comment from my colleague that might give you another option. It looks to boil down to the idea of splitting out the values file into a separate package, keeping changes to it separate while retaining the helm chart package. Or perhaps one of the ideas floated in this thread.
I’d be interested to hear what you think, or of course if you have any further questions!
In first place, I want to apologize that I didn’t check forum more carefully, but PoC implementation exhausted me .
From your and other posts, It looks like that helm improvement is very important for your customers. Nowadays, Helm Charts in very popular package manager and Octopus should follow this idea to be top in this.
In meanwhile, I use alternative solutions, but any idea from previous post force me to do something instead of help me.
Thank you for following up. I think we’d all agree that this feature added into the Helm step would be very useful in cases like yours. Having to work around it with alternative solutions is absolutely not ideal. I haven’t seen it discussed internally super recently, however I have brought it up again mentioning your request as perhaps we can get it prioritized higher given the number of requests for it.
My apologies for the inconvenience, but I do greatly appreciate your suggestion on how we can improve the Octopus experience.
Let us know if you have any questions or concerns going forward, and I’ll reach out with any update.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.