-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] using environments feature #273
Comments
@davidovich Hey. Thanks for trying helmfile! One of expected use-cases of #247 is to transform your structure into something like:
Whereas the helmfiles:
- apps/*/helmfile.yaml And
To avoid that, you should rewrite your helmfile.yaml and values.yaml into something like:
Whereas
|
You should specify the environment name by a flag If you have specific use-case that requires helmfile to set the env according to an environment variable, please file an another feature request! |
@mumoshu thank you very much for this response, it gives me many options, and a better understanding of the new features. I don't know what you think, but it would maybe be beneficial to be able to reference releases in the
|
@mumoshu The proposed solution does not seem to work,
When I issue a
As you see, {{ .Environment.Name }} seems empty |
In fact, you mention this exact issue in #254 (comment) I have a solution (double parse), I will prepare a PR. I am not sure if there is an issue on this specific topic. For reference, this is the PR #308. |
@davidovich Hey!
Yeah, that's definitely beneficial and feasible! Does it make the double render feature #308 unnecessary to you? Although I find the double render feature super useful, I'm struggling about how we could settle it, escaped templates(#297 (comment)), mixed templating(#297 (comment)), and chart hooks(#297 (comment)) altogether, in the simplest possible yet effective form. |
@mumoshu Hi! I still think the double render is a more generalized approach. In fact, the idea came to me when I opened the code to see why I couldn't reference the .Environment.Name as you suggested (which was later fixed). I thought that having a complete env available could help other implementation ideas. I have a feeling that this fixes all the environment self-references. Am I right in thinking that the double parse would fix all the attempts you mention to devise a syntax for templating ? We can take this to #308 |
Almost. Use-cases like chart hooks(#297) aren't covered with double rendering, but it requires us to execute a template at chart hook runtime. |
Yeah, I believe so, too! My only concern is, honestly, it is just scary because I've already seen many edge-cases. But it doesn't negate the usefulness of double rendering. So to move forward, would you mind if we do both (1) merge your double rendering (#308) AND (2) make helmfile.yaml templating optional by changing helmfile to require This way, even in case we find any more edge-cases in double rendering that can't be fixed in a straightforward way, we can fall-back to add our own syntax/language to make vanilla helmfile.yaml programmable without gotmpl e.g. #197. In case we find no more edge-cases in double rendering, it just remains the most versatile way to write your helmfile. How dose it sound to you? |
Why so? The first pass renders the environment, then you can use the result to describe your hooks, then the final render has all the info to run the hooks e.g.
Would become:
|
My thought is that |
@davidovich Can we close this now? |
Thanks @mumoshu, closing. |
#253 brings environments control to helmfile. Nice. #266 allows inclusions of many helmfiles controlled by one master helmfile. Excellent.
I had just finished an implementation (with helmfile 0.25.3) which does something similar, but I am not sure how to use the new feature to implement my use-case. Below explains the current situation, if anyone can comment on an alternative, it would be very valuable.
Below are the contents of the serviceA.yaml.
DEPLOYMENT_ENV is injected by the ci-system, but it would be nice that helmfile would work without it.
I am wondering if you have any input on how I should refactor or structure this to use the environments and/or helmfile inclusion features.
Note that each release can have or leave out defaults, and can have or leave out configuration for an environment. Right now, this structure forces me to have a duplicated file in the environment directory even if it is not required. I'd like to tend towards a more generalized structure if at all possible.
Thanks for all the work!
The text was updated successfully, but these errors were encountered: