Support for specifying a kubeconfig file instead of separate params about concourse-helm-resource HOT 9 CLOSED

I'd like to use this kind of thing in conjunction with https://github.com/concourse/pool-resource pick the right environment and deploy into it.

from concourse-helm-resource.

I agree, zlabjp/kubernetes-resource allows to do that and it is quite useful to be able to specify a whole kubeconfig file instead of a bunch of parameters.

from concourse-helm-resource.

Another vote for this - my use case is we're writing a pipeline that provisions a Kubernetes and then deploys stuff to it using Helm, all as one pipeline. The Kubernetes cluster is a means to an end in this use case, so it doesn't make sense to have that be two separate pipelines.

from concourse-helm-resource.

I do absolutely understand your use-case, it makes complete sense to me and we might be doing a similar thing ourselves soon.
However I think that this does not really map to the concourse notion of a resource. A resource is supposed to be something that stays and has a state (check operation). I can't implement the check if I don't have a cluster config in the resource definition.
So I suggest you just use a task for it, in the "concourse world" that's a better fit for what you're doing.

What I'd absolutely accept and like is a PR that factors out some things from this resource into a base image that could then be used in the task. That task image would then take params like the kubeconfig file and the release name and possibly the action to perform (create, delete)

from concourse-helm-resource.

However I think that this does not really map to the concourse notion of a resource. A resource is supposed to be something that stays and has a state (check operation). I can't implement the check if I don't have a cluster config in the resource definition.

I don't see that as the bright line as being the check. There are lots of times when the check isn't really relevant -- pretty much any time the purpose of a pipeline is to put.

For me, the bright line is introspection vs extrospection.

Tasks should be introspective. The task should describe what has to be done assuming all the task prerequisites are met via Concourse gets. Tasks should produce local artifacts, and the local artifacts should be placed in the appropriate place with the put step.

Yes, the check step is interesting and important, but mostly for triggering. If there's no need to trigger, then it's perfectly fine for the check step to give an empty result, and there are plenty of examples of noop checks.

If you let a task perform download or upload, you have to give it access to all the credentials required to do so. These rightly belong as part of the pipeline, not exposed to a task.

Also, there are plenty of examples of resources that allow one to override the default/check location as a parameter. For each of these resources, the output of the build is not being uploaded to the same place that the check used.

I don't understand why it would be bad to be able to tell the resource that "I don't care about the check, just return the empty set please" for cases like mine where I don't care about the check results anyway.

Thanks for the great resource, it's been quite helpful.

from concourse-helm-resource.

Another +1

from concourse-helm-resource.

So happy to see this implemented. Any predictions as to when a release will be cut with the feature in?

from concourse-helm-resource.

@DanielJonesEB in the short term, you can use my images at hstenzel/concourse-helm-resource to experiment. It's an autobuild of my fork, currently sync'd to linkyard/concourse-helm-resource master at the PR merge. But we're also waiting for an official release. And FYI, I do not expect to keep that fork up to date . . .

For those following along, #117 resolves this issue.

from concourse-helm-resource.

I've just released 2.14.0 which contains this change

from concourse-helm-resource.