3 ms·
You're not alone and it's great to see others thinking this way. We're looking at making it easier for people to bring-your-own-helm-chart[1] and have GitLab d
by Snappy 9y ago
You're not alone and it's great to see others thinking this way.
We're looking at making it easier for people to bring-your-own-helm-chart[1] and have GitLab deploy it. There's value in keeping the chart in the project repo, and there's value in decoupling the chart and putting in a different repo. I'm fascinated to see which becomes best practice.
[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/29969 https://gitlab.com/gitlab-org/gitlab-ce/issues/29969
- lobster_johnson 9y agoWe considered keeping all the charts together in one repo. But it's just simpler for developers. I can't say I'm thrilled to put deployment-specific values in the repo. Maybe the solution is to keep the chart itself, with its defaults, in the repo, and then have a configmap or third-party resource in Kubernetes that contains the values. To deploy anything, you use the Kubernetes API to find the app's values and merge them into the template. I wouldn't be surprised if one day Kubernetes might support that kind of templating. I also wonder what kind of system Google uses internally. They have been rather silent about offering good advice here.
- Snappy 9y agoI hope eventually you can use environment-specific variables[1] in GitLab to manage your deploy variables. [1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/20367 https://gitlab.com/gitlab-org/gitlab-ce/issues/20367
- deleted 9y ago[deleted]