Closed kmala closed 8 years ago
I will remove it after merging this and ci job to publish the charts along with updating the readme file.
Giving it 👍 as long as you are sure this is up to date with the current charts :)
@@ master #271 diff @@
==========================================
Files 6 6
Lines 381 381
Methods 0 0
Messages 0 0
Branches 0 0
==========================================
Hits 210 210
Misses 151 151
Partials 20 20
Powered by Codecov. Last update 5c0042f...0241013
@kmala-- this looks pretty good. I have just a couple questions.
/manifests
directory soon. That would be great. When that happens, what's the new workflow for a contributor who has (more than likely) installed all of Workflow into a cluster and now wishes to replace just the router component with a custom build? (i.e. You've helm
installed Workflow and that has resulted in a Workflow release in your cluster, but to hack on router, you want to replace a few discrete pieces of that Workflow release. I'm not sure how that is accomplished.)
- Is the idea (in general), that each Workflow component will have its own chart sourced embedded within its own repo? Will the Workflow chart reference each of these as dependencies?
yes, each will be in its own repo and workflow will add these add dependencies.
2.What's the workflow for deploying the router's chart? I imagine each time we tag a release, we want packaging and uploading of the chart to be automatic, right?
if you want just router you can helm install charts.deis.com/router-<version>
or you install workflow and the router will be part of it. Tagging a new release will automatically package and upload the chart which will doe through our CI(I am working on it).
3.What's the new workflow for a contributor who has (more than likely) installed all of Workflow into a cluster and now wishes to replace just the router component with a custom build?
Currently, you either hack on the manifest through kubectl or install a new workflow with the latest router.But i would want something like helm upgrade <workflow-release-name> <dependency-name> <chart of the dependency>
to happen and i am discussing with helm team for this use case.
You can see more details on how everything should work here https://github.com/deis/charts/issues/350#issuecomment-251587320
if you want just router you can helm install charts.deis.com/router-
or you install workflow and the router will be part of it. Tagging a new release will automatically package and upload the chart which will doe through our CI(I am working on it).
Sorry... I need to restate my question more clearly...
What is the process for taking the chart sources from this repo, archiving them, and uploading them to a repository? Ideally, what is the process for doing this automatically when a router release gets tagged in github?
But i would want something like helm upgrade
to happen and i am discussing with helm team for this use case.
👍 I think that's a valid use case. I want to update a dependency of another chart without updating the whole thing. Cool.
When ever we tag a release there is already a job which runs to verify the image and push it to the deis org with the release tag, i want to add to the same job once it uploads the new image replace the org, version in the values.yaml file in the charts directory, run helm publish <router>
and upload the tar.gz to our hosting directory(s3).
Ok. Cool. Should that be part of this PR? Or you want to tackle that separately?
that will be part of the our jobs infrastructure... it will be just one job for all the repos.
i will merge this PR once that has been setup.
Got it.
Do you want to ditch the
manifests
dir now or when we have fully moved over?