roboll / helmfile Goto Github PK
View Code? Open in Web Editor NEWDeploy Kubernetes Helm Charts
License: MIT License
Deploy Kubernetes Helm Charts
License: MIT License
The PR #78 adds env variable interpolation to repository URLs, but I forgot to add a relevant section in the Readme and/or an example.
To simplify building a hierarchy of values files "outside" of the helmfile, it would be useful for deduplication to specify a set of default files to always load. On top of that, the key-value map of the releases could be made available for interpolation:
...
defaults:
values:
- "./values/all/traefik.yaml"
- "./values/{{ release.name }}/traefik.yaml"
releases:
- name: traefik
namespace: platform
chart: stable/traefik
version: 1.24.1
What do you guys think about this?
When I try to run helmfile -f charts.yml diff
or helmfile -f charts.yml diff --sync-repos
it fails as follows:
exec: helm diff mq-demo reg-stage/rabbitmq
exec: helm diff terminator local/terminator
Error: file "local/terminator" not found
Error: plugin "diff" exited with error
Error: file "reg-stage/rabbitmq" not found
Error: plugin "diff" exited with error
err: exit status 1
err: exit status 1
with the helmfile:
repositories:
- name: local
url: http://127.0.0.1:8879/charts
- name: reg-stage
url: <another-url>
charts:
- name: terminator # helm deployment name
chart: local/terminator # chart reference
- name: mq-demo
chart: reg-stage/rabbitmq
Am I doing something wrong or is this a bug?
Extracted from #60 (comment)
TL;DR; Not specifying --reset-values
while calling out helm upgrade --install
in the context of Helmfile seems completely wrong to me right now.
Can we just force it?
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x56a170]
goroutine 1 [running]:
github.com/roboll/helmfile/vendor/github.com/urfave/cli.HandleAction.func1(0xc4200476f8)
/Users/kamsz/go/src/github.com/roboll/helmfile/vendor/github.com/urfave/cli/app.go:474 +0x2c8
panic(0x59aa40, 0x6b78e0)
/usr/local/Cellar/go/1.9.3/libexec/src/runtime/panic.go:491 +0x283
main.before(0xc4200ae280, 0xc42000a800, 0x20, 0x18, 0xc42008e5d0, 0xc42008e5d0)
/Users/kamsz/go/src/github.com/roboll/helmfile/main.go:251 +0x150
main.main.func3(0xc4200ae280, 0x0, 0x0)
/Users/kamsz/go/src/github.com/roboll/helmfile/main.go:140 +0x40
reflect.Value.call(0x591ec0, 0x5d2e20, 0x13, 0x5c75b8, 0x4, 0xc420047698, 0x1, 0x1, 0xc420047618, 0x5bf120, ...)
/usr/local/Cellar/go/1.9.3/libexec/src/reflect/value.go:434 +0x905
reflect.Value.Call(0x591ec0, 0x5d2e20, 0x13, 0xc420047698, 0x1, 0x1, 0xc4200ae280, 0x7f2112147ee0, 0x0)
/usr/local/Cellar/go/1.9.3/libexec/src/reflect/value.go:302 +0xa4
github.com/roboll/helmfile/vendor/github.com/urfave/cli.HandleAction(0x591ec0, 0x5d2e20, 0xc4200ae280, 0x0, 0x0)
/Users/kamsz/go/src/github.com/roboll/helmfile/vendor/github.com/urfave/cli/app.go:483 +0x180
github.com/roboll/helmfile/vendor/github.com/urfave/cli.Command.Run(0x5c7640, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x5d162b, 0x33, 0x0, ...)
/Users/kamsz/go/src/github.com/roboll/helmfile/vendor/github.com/urfave/cli/command.go:186 +0x9ed
github.com/roboll/helmfile/vendor/github.com/urfave/cli.(*App).Run(0xc420001080, 0xc42000e080, 0x4, 0x4, 0x0, 0x0)
/Users/kamsz/go/src/github.com/roboll/helmfile/vendor/github.com/urfave/cli/app.go:237 +0x57d
main.main()
/Users/kamsz/go/src/github.com/roboll/helmfile/main.go:229 +0xbd5
As seen in #55 (comment)
We should add a validation for releases[].chart
!
I would be interested in getting helmfile integrated with the helm-secrets project. From looking at it, it might be possible to just change the helm binary that is called to the helm-secrets wrapper with a command line flag.
https://github.com/futuresimple/helm-secrets
How are others handling secrets?
Extracted from #49 (comment)
This still seems like a scope-creep regarding what helmfile do today, yet I find nowhere to do this cleanly outside of helmfile.
I really like the idea of this tool, but it would be important to know under which license it is running, in order to safely make it part of a workflow. Is it MIT? Currently, it seems like no license (https://choosealicense.com/no-license/) ..
Thoughts on allowing version constraints to be specified.
~2.2.0
to get the latest version of the 2.2.xWhen there is an error, one has to parse through the entire output to find out what went wrong. A summary of releases and their status (or even abbreviated error message) would help to quickly identify the problem.
It would be awesome if Helmfile could cause Charts.yml to interpolate environment variables.
I currently have my project's deployment in a chart directory in my repo. I pass environment variables in via set
:
helm upgrade my-project-$NODE_ENV ./kubernetes/my-project/ \
--set namespace=$NODE_ENV \
--set web.imageName=$WEB_NAME \
--set api.imageName=$API_NAME \
--set env.dockerRepoUrl=$DOCKER_REPO_PREFIX \
--set env.dockerImageTag=$DOCKER_REPO_TAG \
--set env.hostname=$NODE_ENV.$KUBERNETES_HOST \
--install --debug
This is just about the only imperative part of my build step. I'd love to move it into the Helmfile format, but it'd be nice not to have to add a step to run my Helmfile through envsubst
.
What do you think of the idea of Helmfile doing environment variable substitution on its own?
While trying to modularize our deployment slightly, we broke out our Helmfile into two different sets which we had residing in the same directory.
Attempting to use the -f
command with the helmfile repos
command, we receive an error around the flag not being defined properly
Hi,
It isn't clear how can put the values files inside source control (e.g. GIT). The best option will be allowing additional option in charts.yaml:
valueRepositories:
- name: values
url: http://roboll.io/values
Thanks
Extracted from #60 (comment)
Currently, helmfile delete
runs helm delete --purge
. This might be unexpected for helm users. Shouldn't purge be an optional flag?
Alternatively, we could have two actual commands for convenience and to make it crystal clear:
helmfile delete
helmfile purge
Examines helmfiles for possible issues.
The command validates the syntax of the default or specified helmfile(s) and runs a series of tests to verify that they are well-formed.
If the linter encounters things that will cause the chart to fail installation, it will emit [ERROR] messages. If it encounters issues that break with convention or recommendation, it will emit [WARNING] messages (linting).
The following could be reported:
helm validate [flags]
--strict Fail on lint warnings
--file valueFiles Specify helmfile (can specify multiple) (default `helmfile.yaml`)
--follow-values check syntax of specified values files
-e, --env Set environment variables
--env-file Read in a file of environment variables
--check-variables=true Check whether all required variables have been specified. (default `true`)
Inspired by helm lint, terraform validate and docker run.
Is it possible to install a specific version of a chart?
Similar to the one for kubernetes-on-aws.
It will help users and maintainers have another aspect of confidence in their project and tooling, while allowing maintainers to try to contact prod users in case it seems necessary(like before making a breaking change, scope-creep, etc.
I have quite a large helmfile and helm (or tiller) is starting to time out when deploying to my local cluster in minikube. Would it be possible to have an argument to limit the number of concurrent requests being made to helm at a time. Maybe something like --max-connections=X
, if unset you could leave it as unlimited, but if set helmfile
should only make at most X
requests at a time.
The --kube-context
CLI flag does not do anything. Passing in different contexts simply uses the default context. Even passing in a bad context name uses the default. The preview execution that is printed out is clearly not what is actually running.
Example command that will use default context:
$ helmfile --kube-context BAD_CONTEXT_NAME sync
exec: helm upgrade --install test stable/datadog --kube-context BAD_CONTEXT
...
When run manually, helm is able to accept context and apply just like helmfile should:
helm upgrade --install test stable/datadog --kube-context staging --file test.yaml
As you can see helm errors out if passed in a bad context:
$ helm list --kube-context BAD_CONTEXT_NAME
Error: could not get kubernetes config for context 'BAD_CONTEXT_NAME': context "BAD_CONTEXT_NAME" does not exist
2018/03/02 14:34:33 warn: charts.yaml is loaded: charts.yaml is deprecated in favor of helmfile.yaml. See #25 for more information
2018/03/02 14:34:33 err: open helmfile.yaml: no such file or directory
Just a note to add test -z "$(find . -path ./vendor -prune -type f -o -name '*.go' -exec gofmt -d {} + | tee /dev/stderr)"
to make check
.
Would it be possible to enhance the env var interpolation feature, so that we could safely git-commit a helmfile referencing private chart repositories which requires authn?
For example, we can use private git repos as helm chart repos like described in https://github.com/kmzfs/helm-repo-in-github#how-to-use-it-as-a-helm-repo.
However, it requires you to include a sensitive information(=auth credential) in repository urls.
Simply doing it results in a charts.yaml like:
respositories:
- name: your-private-git-repo-hosted-charts
url: https://[email protected]/kmzfs/helm-repo-in-github/master/
which ins't very good to be committed into your git repo.
If the repositories
section had a support for env var interpolation, it would look like:
respositories:
- name: your-private-git-repo-hosted-charts
url: "https://{{ env \"GITHUB_TOKEN\"}}@raw.githubusercontent.com/kmzfs/helm-repo-in-github/master/"
This makes helmfile safe enough to be committed into a git repo.
Note that running helm sync
would result in printing the repository url containing the token like:
exec: helm repo add your-private-git-repo-hosted-charts https://[email protected]/kmzfs/helm-repo-in-github/master/
I'd like to fix it, too. However, it could be done in an another github issue.
The help text for the charts command currently is:
helm repo upgrade --install
Shouldn't it be:
helm upgrade --install
I'm creating a small chart with out StorageClass
configuration, but there's already one present with the same name, so I'd like helm to "take it under its wings". This can be done by running helm install --replace
. However, this goes against the idempotent way of running helm upgrade --install
that we do when we run the charts
or sync
action.
Could we:
install
instead of an upgrade
?--replace
directly in the state file (now I have to do it on the command-line and it's valid for all releases, so I have to use the label selector).I really want to use 1 charts.yaml
file for my project. But I want to be able to control the charts separate as well..
Would a tagging system be a good idea?
Example charts.yaml:
charts:
- name: a1
chart: ../charts/c1/
tags:
- tag1
- name: a2
chart: ../charts/c1/
tags:
- tag1
- tag2
- name: b1
chart: ../charts/c1/
tags:
- tag3
- name: c1
chart: ../charts/c1/
Then helmfile could be used like:
# sync a1, a2
helmfile --tags tag1 sync
# sync a1, a2, b1
helmfile --tags tag1,tag3 sync
# sync all
helmfile sync
Hi, maybe adding a requirements
property to each chart section could tell helmfile to install dependencies first? Is that an idea? Is there a way to know if dependencies are ready?
We should add a couple of new-lines to improve readability of the output. It's difficult to parse the output quickly:
I have a loop that runs helmfile diff 100 times. Sometimes the following value will output true, but the majority of the time it has the correct value
- name: config.s3.bucket
value: '{{ env "S3_BUCKET" }}'
In the case of an error, the error message is printed without any indication of the affected release. For example, in the middle of two successful releases, I found the following error for third one. But I had to manually go through the helmfile to find out which one it might have been.
Error: UPGRADE FAILED: failed to create patch: failed to get versionedObject: unable to convert unstructured object to apps/v1beta1, Kind=StatefulSet: cannot restore struct from: string
We use Helmfile and love the simplicity of managing the manifests at this level.
One reality we have is that people at times make manual changes to the infrastructure and charts change over time. We would love the ability to be able to run something like helm diff with the context of the helmfile as a way of indicating the changes that would be made.
Specifically being able to understand the impact of a given PR in our CI/CD system would be really wonderful.
Hi,
first of all: Awesome idea and library. Thank you.
Many tools and libraries use yml
as a file suffix for YAML files. I intuitively created a file called charts.yml
.
Do you think you can support both file suffixes: yaml
and yml
?
Would there be any appetite to allow inlining values in their natural nested form (instead of name/value pair). I imagine it would require temporary file creation during execution, unless there are libs to convert nested yaml to json dot notation. Not sure if that is beyond helmfile's remit.
eg:
charts:
- name: vault
namespace: vault
chart: roboll/vault-secret-manager
inlined_values:
some:
quite:
- name: deep
value:
variable: {{ env "VAL" }}
Why are those releases not readily installable on osx? What extra step is needed to consume those files?
We would like to deploy the same group of charts to the same cluster in different namespaces (branch environments)
Would there be any desire to see that in helmfile? eg --kube-namespace
we're using a private chart repo with token auth in github: see https://medium.com/@kavehmz/using-a-private-github-repo-as-helm-chart-repo-https-access-95629b2af27c
and when trying to switch from a large umbrellla chart to use helmfile
, running into an issue that the chart can't be found
here's a sample of the helmfile
:
repositories:
- name: authtest
url: https://[email protected]/org/helmrepo/master/stable
charts:
- name: dev-service
namespace: dev
chart: authtest/service
# version: 1.1.1
values:
- service-values.yaml # (relative path to manifest)
and the output of helmfile -f charts.yaml sync
:
exec: helm repo add authtest https://[email protected]/org/helmrepo/master/stable
"authtest" has been added to your repositories
exec: helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "authtest" chart repository
...Successfully got an update from the "roboll" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈
exec: helm upgrade --install dev-service authtest/service --namespace dev --values .../service-values.yaml
Error: file "authtest/service" not found
err: exit status 1```
Extracted from #60 (comment)
Please see the discussion made there for more context.
Maybe use goreleaser in the CI to do so?
I can make a PR, but can a maintainer help by adding the githb auth token and getting it working?
Use Case: In my CI flow I have multiple helm repositories to install (initially 3, will be more). I initialize helm and then add the repositories with: helmfile repos
. However, I'm seeing most of the time only 1 or 2 of the repositories show up on subsequent helmfile charts
or using helm repo list
.
I don't see any additional arguments to helmfile I need to make this work or anything I'm doing incorrectly. Please let me know if I'm missing something. See #46 for exact steps to test/reproduce.
Background: it appears this is because the calls to helm repo add
are done asynchronously and helm doesn't fully support it. I am running on 3 node kubernetes cluster with kubernetes 1.9.3 with latest versions of helm/helmfile (info below).
What I've tried: I've tried this test case with both the released helmfile (https://github.com/roboll/helmfile/releases/tag/v0.8) and latest master and it has the same issue. I also have tried with the latest release of helm (https://github.com/kubernetes/helm/releases/tag/v2.8.1) as well as the latest version of master (helm/helm@b49a396 - March 5th). I though this bug (helm/helm#3253) in helm around client concurrency might fix the issue with helm, however it did not fix the issue even when I ran with helm from master. That said, even if there was a fix in helm master for this, I think helmfile should strongly consider not requiring the absolute latest version of helm.
Potential Fix: I've created a potential fix in a pull request (#46) which just makes the calls to helm repo add
synchronous. This is slightly slower, but the calls to helm repo add
are pretty fast and having them reliably work is more important than a fraction of a second.
I've started using helmfile
, and after a couple of days of use, I am missing a way to do helm dependency update
. Should it be a part of helmfile? And included in sync
I'm a bit hesitant to propose this but how about supporting oneshot jobs in helmfile?
An oneshot job can be either a K8S job or a pod created via helm upgrade --install
to accomplish a job like db migration, enqueueing a large job to a kind of workflow system, etc.
As of today, we have to resort a variant of kubectl run --image $img
to run an oneshot job, even in a situation that our regular app are managed by helm and shared the image, envvars with oneshot jobs.
AFAIK, there's no such tool to support this use-case. And supporting it in helmfile allows us to provide a more docker-compose-like U/X to helm users, but the docker-build feature.
Thoughts?
cc/ @roboll @sstarcher
There is a subtle issue with Helmfile when:
-f
flag is used to reference a file outside of the current working directoryWhat Helmfile is currently doing in this case is resolving those relative file paths to against the PWD and not against the Helmfile's directory.
I've started using helmfile
, and after a couple of days of use, I am missing a way to do helm status
on the repo's that the helmfile points to..
Running helmfile sync
, helmfile delete
and then helmfile sync
again results in helm/helm#3208.
More concretely, you get something like:
$ PROJECT=deis/empty-testbed ENV=staging IMAGE=mumoshu/golang-k8s-aws:1.9.1 COMMAND='go' SERVICE_ACCOUNT=default helmfile sync
exec: helm repo add brigade https://azure.github.io/brigade
"brigade" has been added to your repositories
exec: helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "incubator" chart repository
...Successfully got an update from the "kubeherd" chart repository
...Successfully got an update from the "es-operator" chart repository
...Successfully got an update from the "brigade" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈
exec: helm upgrade --install brigade-project brigade/brigade-project --values myvalues.yaml --set secrets.env=staging,secrets.image=mumoshu/golang-k8s-aws:1.9.1,secrets.command=go,secrets.serviceAccount=default,project=deis/empty-testbed,repository=github.com/deis/empty-testbed,cloneURL=https://github.com/deis/empty-testbed.git
WARNING: Namespace doesn't match with previous. Release will be deployed to kube-system
Error: UPGRADE FAILED: "brigade-project" has no deployed releases
err: exit status 1
This seems to prevent us from just re-running helmfile sync
without changing charts[].name
in charts.yaml each time you run helmfile delete
.
Would it be better for helmfile to just purge releases so that we don't need to change charts[].name
so often?
Hi,
just stumbled over this tool and could not image how to live without it! Idea is brilliant as it is simple. Thanks for that. :)
I was just wondering, if there is an argument which limits the list of charts to work on by some kind of expression. Its not always desired to iterate across the whole list of charts. Nevertheless its easily possible to write just a charts.yaml
which lists only the desired charts, but this is some kind of cumbersome.
Image something like that: helmfile charts --limit "metrics*"
which just works on the charts where the given glob pattern match against.
Using Helm CLI shows that one Helm release can include several Helm charts - one main chart and several subcharts. Am I missing something or should charts.yaml
therefore be releases.yaml
?
Example:
Generic chart: rails-app
Unique releases: dev-example-com, prod-example-com, dev-example-org, prod-example-org
Workflow:
values.yaml
values.yaml
One cluster, many charts, more releases 🤔
“Helm deployment” here should be “Helm release” also. “Deployment” is a very specific Kubernetes term, and not a Helm term at all.
Am I wrong?
Hi there,
I just wanted to rewrite this piece of working code:
helm install stable/prometheus --name prom --set rbac.create=false --namespace=prometheus
my simple helmfile:
vim charts.yaml
...
context: <my_context>
releases:
# Published chart example
- name: prometheusnorbac # name of this release
namespace: prometheus # target namespace
chart: stable/prometheus # the chart being installed to create this release, referenced by `repository/chart` syntax
set: # values (--set)
- name: rbac.create
value: false
...
wq!
When I run:
./helmfile -f charts.yaml sync
exec: helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈
Then chcek helm list
helm list
NAME REVISION UPDATED STATUS CHART NAMESPACE
prom 1 Thu Mar 15 14:22:19 2018 DEPLOYED prometheus-5.4.3 prometheus
promt 1 Fri Mar 16 11:50:31 2018 FAILED prometheus-5.4.3 prometheus
promtemp 1 Fri Mar 16 10:58:31 2018 DEPLOYED prometheus-5.4.3 prometheus
So from helm list
output can be seen that deployment for prometheusnorbac
was never finished.
Tested OS's
fatal error: concurrent map writes
goroutine 6 [running]:
runtime.throw(0x11c4712, 0x15)
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/panic.go:605 +0x95 fp=0xc420043908 sp=0xc4200438e8 pc=0x10292f5
runtime.mapassign_faststr(0x1194640, 0xc420078510, 0x11c2e6b, 0xe, 0x12d3980)
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/hashmap_fast.go:861 +0x4da fp=0xc420043988 sp=0xc420043908 pc=0x100c5ba
text/template.(*Template).associate(0xc420056140, 0xc420056140, 0xc4200ce100, 0xe, 0x1, 0x2)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/template.go:224 +0xad fp=0xc4200439c8 sp=0xc420043988 pc=0x10ff96d
text/template.(*Template).AddParseTree(0xc420056140, 0x11c2e6b, 0xe, 0xc4200ce100, 0x0, 0x0, 0x0)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/template.go:128 +0x11c fp=0xc420043a30 sp=0xc4200439c8 pc=0x10fe8cc
text/template.(*Template).Parse(0xc420056140, 0xc420010340, 0x34, 0x10d1eaf, 0xc420048de0, 0x2)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/template.go:205 +0x20a fp=0xc420043b40 sp=0xc420043a30 pc=0x10ff64a
github.com/roboll/helmfile/state.renderTemplateString(0xc420010340, 0x34, 0x2, 0xc420010340, 0x34, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:87 +0x45 fp=0xc420043b98 sp=0xc420043b40 pc=0x1148845
github.com/roboll/helmfile/state.flagsForChart(0xc42001a240, 0x22, 0xc420043f50, 0x0, 0x0, 0x0, 0x0, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:246 +0x274 fp=0xc420043e10 sp=0xc420043b98 pc=0x11498f4
github.com/roboll/helmfile/state.(*HelmState).DiffCharts.func1(0xc420082500, 0xc42000adc0, 0x12d3218, 0x0, 0x0, 0x12a1820, 0xc420056980, 0xc4200165c0, 0xc420016410, 0xe, ...)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:171 +0x71 fp=0xc420043f10 sp=0xc420043e10 pc=0x114b371
runtime.goexit()
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/asm_amd64.s:2337 +0x1 fp=0xc420043f18 sp=0xc420043f10 pc=0x1055841
created by github.com/roboll/helmfile/state.(*HelmState).DiffCharts
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:168 +0x1e4
goroutine 1 [semacquire]:
sync.runtime_Semacquire(0xc4200165cc)
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/sema.go:56 +0x39
sync.(*WaitGroup).Wait(0xc4200165c0)
/usr/local/Cellar/go/1.9.4/libexec/src/sync/waitgroup.go:131 +0x72
github.com/roboll/helmfile/state.(*HelmState).DiffCharts(0xc420082500, 0x12a1820, 0xc420056980, 0x12d3218, 0x0, 0x0, 0x60000000008, 0x18, 0x18)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:190 +0x239
main.main.func3(0xc42009a280, 0x0, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/main.go:150 +0x17f
reflect.Value.call(0x118c9c0, 0x11cc568, 0x13, 0x11c12b8, 0x4, 0xc420043778, 0x1, 0x1, 0xc4200436f8, 0x11b8e20, ...)
/usr/local/Cellar/go/1.9.4/libexec/src/reflect/value.go:434 +0x905
reflect.Value.Call(0x118c9c0, 0x11cc568, 0x13, 0xc420043778, 0x1, 0x1, 0xc42009a280, 0x1319988, 0x0)
/usr/local/Cellar/go/1.9.4/libexec/src/reflect/value.go:302 +0xa4
github.com/roboll/helmfile/vendor/github.com/urfave/cli.HandleAction(0x118c9c0, 0x11cc568, 0xc42009a280, 0x0, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/vendor/github.com/urfave/cli/app.go:483 +0x180
github.com/roboll/helmfile/vendor/github.com/urfave/cli.Command.Run(0x11c133c, 0x4, 0x0, 0x0, 0x0, 0x0, 0x0, 0x11caf4b, 0x33, 0x0, ...)
/Users/sstarcher/go/src/github.com/roboll/helmfile/vendor/github.com/urfave/cli/command.go:186 +0x9ed
github.com/roboll/helmfile/vendor/github.com/urfave/cli.(*App).Run(0xc420001080, 0xc42000a060, 0x2, 0x2, 0x0, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/vendor/github.com/urfave/cli/app.go:237 +0x57d
main.main()
/Users/sstarcher/go/src/github.com/roboll/helmfile/main.go:212 +0x9ea
goroutine 5 [runnable]:
text/template.(*Template).Execute(0xc420056140, 0x129f340, 0xc420100000, 0x0, 0x0, 0x0, 0x2)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/exec.go:179 +0x76
github.com/roboll/helmfile/state.renderTemplateString(0xc4200d0000, 0x39, 0x2, 0xc4200d0000, 0x39, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:93 +0xad
github.com/roboll/helmfile/state.flagsForChart(0xc42001a240, 0x22, 0xc420077f50, 0x0, 0x0, 0x0, 0x0, 0x0)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:246 +0x274
github.com/roboll/helmfile/state.(*HelmState).DiffCharts.func1(0xc420082500, 0xc42000adc0, 0x12d3218, 0x0, 0x0, 0x12a1820, 0xc420056980, 0xc4200165c0, 0xc420018440, 0x13, ...)
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:171 +0x71
created by github.com/roboll/helmfile/state.(*HelmState).DiffCharts
/Users/sstarcher/go/src/github.com/roboll/helmfile/state/state.go:168 +0x1e4
goroutine 7 [runnable]:
text/template/parse.(*lexer).emit(0xc4200ca180, 0x6)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/parse/lex.go:156 +0xc5
text/template/parse.lexText(0xc4200ca180, 0x6)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/parse/lex.go:269 +0x1e0
text/template/parse.(*lexer).run(0xc4200ca180)
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/parse/lex.go:231 +0x5f
created by text/template/parse.lex
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/parse/lex.go:224 +0x15f
goroutine 17 [runnable]:
runtime.goexit1()
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/proc.go:2365 +0x4e
runtime.goexit()
/usr/local/Cellar/go/1.9.4/libexec/src/runtime/asm_amd64.s:2338 +0x6
created by text/template/parse.lex
/usr/local/Cellar/go/1.9.4/libexec/src/text/template/parse/lex.go:224 +0x15f
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.