Hello, prometheus-something chart maintainer here. ;)
Actually, it is quite simple to use https://github.com/helm/chart-testing (and if you're going to use GitHub Actions, https://github.com/helm/chart-testing-action) and/or https://github.com/helm/chart-releaser, which automates all the testing / release procedures (and, of course, only process the one being changed). I can help to setup this if needed. Note that if you're going to use a single repo, please name it prometheus-helm-charts instead of just helm-charts. Forking this repo results in a wierd state (I think I have fork of several "helm-charts" repository on my GitHub, which results being named helm-charts-1, helm-charts-2, etc). Le samedi 20 juin 2020 10:40:47 UTC+2, Augustin Husson a écrit : > > Hello, > > Well having a single repo for each chart would create so much repositories > and IMHO just imagine to create for each of them the CI/CD even if it's the > same each time, is to exausting. ( Yeah I'm a bit lazy) > > Moreover if you have to change one CI/CD for whatever reason you will have > to change it in all of them to keep the same. > > Then it's quite fine to have a single repo of all helm-charts. We can even > imagine to create a bit clever scrip that will only run the test for the > charts that changed. That's not super rocket science I think. > > And perhaps it makes sense actually to split the helm-charts into 2 repo. > One could go to prometheus and will have the helm chart owned by > prometheus. Then another one that will go to prometheus-community that will > contain the others (like the jira-alerts). > > This split is just to provide to the helm chart of > prometheus/alertManager/node-exporter a better visibility and a sort of tag > "official helm chart of prometheus" > > Kinds regards > > Le ven. 19 juin 2020 à 20:14, Mingchin Hsieh <[email protected] > <javascript:>> a écrit : > >> Hi André, >> >> I would take back what I said. I originally intended to not mess-up repos >> under prometheus-community and might think too much on current CI e2e >> testing stucking issues. >> >> Best, >> Mingchin >> >> On Sat, Jun 20, 2020 at 1:50 AM André Bauer <[email protected] >> <javascript:>> wrote: >> >>> Why would you want to add "helm-chart" in the name of the chart and have >>> multiple repos? >>> >>> Imho it would be: >>> >>> helm-charts/prometheus >>> helm-charts/alertmanager >>> helm-charts/... >>> >>> and so on. So being "helm-charts" the repos main directory and the >>> charts inside of it. >>> Adding "helm-chart" to the name would also waste chars in helms limited >>> release name lenght. >>> >>> Maintenance of single repos for every chart would also be total >>> overkill. >>> Imagine alone changes in the CI would be done multiple times. >>> >>> >>> >>> [email protected] schrieb am Freitag, 19. Juni 2020 um 16:36:05 UTC+2: >>> >>>> Hi Stuart, >>>> >>>> No. My ideal expectation would be different repos, unless cost and / or >>>> maintenance is too high. >>>> >>>> Best, >>>> Mingchin >>>> >>>> On Fri, Jun 19, 2020 at 10:26 PM Stuart Clark <[email protected]> >>>> wrote: >>>> >>>>> On 2020-06-19 15:09, Mingchin Hsieh wrote: >>>>> > Hi, >>>>> > >>>>> > I sort of agree with Stuart's idea; only a little tweak: adding >>>>> > helm-chart as prefix or suffix. For example, >>>>> > >>>>> > Prefix approach - >>>>> > helm-chart-prometheus-adapter >>>>> > helm-chart-prometheus-blackbox-exporter >>>>> > helm-chart-prometheus-cloudwatch-exporter >>>>> > helm-chart-prometheus-consul-exporter >>>>> > helm-chart-prometheus-couchdb-exporter >>>>> > helm-chart-prometheus-mongodb-exporter >>>>> > helm-chart-prometheus-mysql-exporter >>>>> > helm-chart-prometheus-nats-exporter >>>>> > helm-chart-prometheus-node-exporter >>>>> > helm-chart-prometheus-operator >>>>> > helm-chart-prometheus-postgres-exporter >>>>> > helm-chart-prometheus-pushgateway >>>>> > helm-chart-prometheus-rabbitmq-exporter >>>>> > helm-chart-prometheus-redis-exporter >>>>> > helm-chart-prometheus-snmp-exporter >>>>> > helm-chart-prometheus-to-sd >>>>> > helm-chart-prometheus >>>>> > >>>>> > Suffix approach - >>>>> > prometheus-adapter-helm-chart >>>>> > prometheus-blackbox-exporter-helm-chart >>>>> > prometheus-cloudwatch-exporter-helm-chart >>>>> > prometheus-consul-exporter-helm-chart >>>>> > prometheus-couchdb-exporter-helm-chart >>>>> > prometheus-mongodb-exporter-helm-chart >>>>> > prometheus-mysql-exporter-helm-chart >>>>> > prometheus-nats-exporter-helm-chart >>>>> > prometheus-node-exporter-helm-chart >>>>> > prometheus-operator-helm-chart >>>>> > prometheus-postgres-exporter-helm-chart >>>>> > prometheus-pushgateway-helm-chart >>>>> > prometheus-rabbitmq-exporter-helm-chart >>>>> > prometheus-redis-exporter-helm-chart >>>>> > prometheus-snmp-exporter-helm-chart >>>>> > prometheus-to-sd-helm-chart >>>>> > prometheus-helm-chart >>>>> > >>>>> > This is due to there are some existing repos in prometheus-community >>>>> > that focus on each component implementation level (e.g. docker image >>>>> > or stand-alone service). Mixing together might be harder to put on >>>>> > hub.helm.sh [1]. But, the owners of prometheus-community hold their >>>>> > right for the final decision. >>>>> > >>>>> > BTW, would any prometheus-community owners / members explain the >>>>> > current testing infrastructure? Currently helm chart testing infra is >>>>> > based on Google Bazel + CircleCI. There's some limitation over there, >>>>> > e.g. the chart owners / approvers debug the testing infra is hard. I >>>>> > think all the current prometheus related helm chart owners would like >>>>> > to know how hard would be for migration / automation. >>>>> > >>>>> > Best, >>>>> > Mingchin >>>>> > >>>>> > On Fri, Jun 19, 2020 at 8:55 PM Stuart Clark >>>>> > <[email protected]> wrote: >>>>> > >>>>> >> On 2020-06-19 13:30, André Bauer wrote: >>>>> >>> Hey guys, >>>>> >>> >>>>> >>> great to see there is already some effort to move the chart out of >>>>> >> the >>>>> >>> stable repo :) >>>>> >>> >>>>> >>> As i understand that "prometheus" is not the perfect fit for the >>>>> >> chart >>>>> >>> name, as it also installs other components from the prometheus eco >>>>> >>> system, i'm also not the biggest fan of umbrella charts. >>>>> >>> From our experience at kiwigrid this can lead to updating issues. >>>>> >>> For example you'd need to update proemtheus server but because of >>>>> >> the >>>>> >>> umbrella it could alreadya fail and exit in the alertmanager >>>>> >> update >>>>> >>> step. >>>>> >>> Therefore we switched to single chart installs now as you're able >>>>> >> to >>>>> >>> update single components, without the need to run the update for >>>>> >> all >>>>> >>> charts under the umbrella, which is much more error resistent from >>>>> >> our >>>>> >>> experience. >>>>> >>> >>>>> >>> Nevertheless an umbrella chart might be good starting point for >>>>> >>> testing Prometheus with all of its available components. >>>>> >>> >>>>> >>> Where i see problems is to deprecate the chart in stable and >>>>> >> change >>>>> >>> the way the chart works in the new repo. >>>>> >>> Maybe such changes should be done in an earlier step in the stable >>>>> >>> chart repo? >>>>> >>> At least doumentation of the upgrade path should be clear and >>>>> >>> possible, without the need to have manual steps like pvc backup / >>>>> >>> restore because the name of the pvc changed. >>>>> >>> >>>>> >> >>>>> >> There are a number of existing charts in the stable repo, which are >>>>> >> mostly for installing indivitual pieces: >>>>> >> >>>>> >> prometheus-adapter >>>>> >> prometheus-blackbox-exporter >>>>> >> prometheus-cloudwatch-exporter >>>>> >> prometheus-consul-exporter >>>>> >> prometheus-couchdb-exporter >>>>> >> prometheus-mongodb-exporter >>>>> >> prometheus-mysql-exporter >>>>> >> prometheus-nats-exporter >>>>> >> prometheus-node-exporter >>>>> >> prometheus-operator >>>>> >> prometheus-postgres-exporter >>>>> >> prometheus-pushgateway >>>>> >> prometheus-rabbitmq-exporter >>>>> >> prometheus-redis-exporter >>>>> >> prometheus-snmp-exporter >>>>> >> prometheus-to-sd >>>>> >> prometheus >>>>> >> >>>>> >> I'd suggest as a first step to just move them all exactly as they >>>>> >> are >>>>> >> into the prometheus/prometheus-community organisation, and then look >>>>> >> at >>>>> >> making changes later... >>>>> >> >>>>> >>>>> Sorry I wasn't clear. You'd expect all those to live in the same repo >>>>> as >>>>> different directories, rather than different repos. You also need >>>>> somewhere to publish the charts to (e.g. Chartmuseum) >>>>> >>>>> -- >>>>> Stuart Clark >>>>> >>>> >>> -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/1bab5efa-a52b-449e-865a-4c84273a2f8co%40googlegroups.com.
