-
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
Proposal: Package helmfile.yaml along with charts and values files #195
Comments
Can you give an example use-case for wanting to locally store the chart packages as opposed to pulling them from the remote repositories? |
I'm interested to hear from you, too @alebabai. Perhaps you're creating a bundle of all the helmfile.yaml and deps, so that you can later run |
Yeap, the main use-case is create some kind of bundle (.tgz for example) like an umbrella chart and install it later via |
@alebabai Very interesting! I'm now wondering how it should work. Say we add a new command I guess, if you are to run
Honestly I don't know much about how Do we need to check the existence of the archive and specifically call helm like Or does |
So, i guess resulting archive should contain helmfile.yaml and all the referenced sub-helmfiles and values.yaml files, templates like you said, but also tgz-archives with charts that had been used in releases.
Helm picks tgz-s only for dependencies that are described in requirements.yaml, but for |
One detail, we can drop |
Ah, sounds good!
Good to know! Thanks. So translating it to helmfile, how about |
The feature request about using values/secrets from within a remote chart #324 relates to this issue a bit. #324 is about packaing values/secrets into chart archives and loading it via helmfile, whereas this issue is about packaging all the deps, values/secrets yamls, and helmfile.yaml files into a single archive. Probably this one is harder, but a more advanced solution to effectively distributing desired states of your k8s apps. |
@alebabai Are you ok with packaging environment values and secrets #267 #255 of all the environments(e.g. dev, test, staging, prod) into a single helmfile archive(tgz)? Or would there be any use-cases that needs an environment specific helmfile archive? That is, which one do you prefer between |
Yeap, i though this way. |
In my opinion |
Updated the issue title accordingly. Please correct me if I have any misunderstandings! |
One thing I'm unsure is that how helmfile can discover executable files contained in a helmfile project to be used by Actually run the exec tmpl exprs and hook commands while packaging, and memorize what's called? |
Related but totally not related, there's a |
I'm not sure if it's more related to #751 or #752 or not, but I'd like the ability to generate a tarball and values.yaml for each release as specified in |
@SE2Dev Can you just create a tarball from |
@mumoshu Technically, yes, if you ran
One could theoretically generate chart packages with the following (although this script wouldn't work for subcharts): PACKAGE_DIR=out
for f in gen/*; do
if [ -d "$f" ]; then
RELEASE_DIR=$f
for f in $RELEASE_DIR/*; do
if [ -d "$f" ]; then
CHART_DIR=$f
CHART_NAME=$(basename $CHART_DIR)
# Generate a Chart.yaml
echo "apiVersion: v2
name: $CHART_NAME
description: Autogenerated chart
type: application
version: 0.1.0
appVersion: ""1.16.0""" > $CHART_DIR/Chart.yaml
# Generate a chart package
tar -zcf $PACKAGE_DIR/$CHART_NAME.tgz -C $RELEASE_DIR $CHART_NAME
fi
done
fi
done The approach above, however, results in the loss of original chart metadata like information, etc. as well as all of the
|
It would be great to have ability to download published charts and package local charts via single api.
For example like it was done with requirements.yaml and
helm dep up
to install charts from tar-balls that are stored locally.It's possible to call
helm fetch
for published charts andhelm dep up & helm package
for local ones.The text was updated successfully, but these errors were encountered: