| cardoe | sean-k-mooney or fungi or clarkb: would any of you do me a favor and drop something on https://review.opendev.org/c/openstack/openstack-helm/+/934013 mentioning that tags don't have to go through the release group / release repo? That they can be created within that repo and then triggered? | 17:36 |
|---|---|---|
| sean-k-mooney | well they can be but it depend on if that project is an offial deliverable fo openstack | 17:37 |
| sean-k-mooney | if they are an offial deliverable then we are ment ot use the shared release automation in the release repo | 17:38 |
| fungi | if it's independent release model then the tc doesn't require tagging to be controlled by the release managers | 17:38 |
| fungi | pretty sure | 17:38 |
| fungi | checking... | 17:38 |
| sean-k-mooney | cardoe: part of the motifation with that is for tags to be be pushsed/signed/built into artifacts by automation that can be auditied rather then people | 17:39 |
| fungi | for example, https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/openstack/sunbeam.config#L22 | 17:40 |
| clarkb | ya a number of things do not go through the release team | 17:40 |
| cardoe | I'm looking to remove https://opendev.org/openstack/openstack-helm/src/commit/d848822dd9e02e5286b72d0c9cd25aab3243dada/keystone/Chart.yaml#L17 from the repo. | 17:40 |
| fungi | so the sunbeam team has permission to push their own git tags | 17:41 |
| cardoe | Which today the project does a new release for every commit to every chart. | 17:41 |
| cardoe | https://opendev.org/openstack/openstack-helm/src/branch/master/releasenotes/notes/keystone.yaml you have to add an entry there | 17:41 |
| fungi | here's what the manual tagging workflow looks like, for teams doing it on their own ad-hoc: https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#tagging-a-release | 17:42 |
| cardoe | I'm all for getting them to the point that they can package up a bunch of commits into a release. | 17:42 |
| sean-k-mooney | its been a long time since i did the manual flow | 17:42 |
| clarkb | its worth noting that if the project were subject to the release team not doing any tags as a workaround for that isn't really any better | 17:43 |
| clarkb | its probably best to find what works for the team then do it rather than skirt technicalities by doing the wrong thing | 17:43 |
| cardoe | If I was to run "helm package keystone" (I'm leaving out some args for brevity sake) it'll build me the keystone helm chart at the current version and that can then be pushed to tarballs.openstack.org and someone out there can do "helm repo add osh tarballs.openstack.org && helm install osh/keystone --version X.Y.Z" | 17:43 |
| fungi | up sides to letting the openstack release managers take care of it is that you propose some metadata describing the release, humans can review that request, and then once it's approved and merges that triggers jobs that create and push tags signed with a release automation key (which then in turn triggers whatever tag/release jobs are configured for the target project) | 17:44 |
| cardoe | I'm looking to make that flow work properly because that's how helm is meant to be used and how others expect helm to be used. | 17:44 |
| cardoe | Today every patch conflicts with every other patch because two people bump the version at the same time. | 17:44 |
| cardoe | https://helm.sh/docs/chart_best_practices/conventions/#version-numbers | 17:45 |
| cardoe | I'm all for not doing a release on every commit and taking "git describe" as the version | 17:46 |
| sean-k-mooney | fungi: with the tag pipline i guess you can still automate the building and uploading of artifact based on a manual tagging | 17:47 |
| cardoe | Ultimately I want to see the project adopt good release cadence with the overall OpenStack project. | 17:47 |
| cardoe | So just trying to craft a way to get there. | 17:50 |
| fungi | sean-k-mooney: correct, the tag pipeline is triggered by any gerrit ref-updated events matching ^refs/tags/.*$ | 17:51 |
| fungi | so doesn't matter who is pushing that tag, whether it's a human-controlled gerrit account or the account that openstack's release automation uses, to gerrit they're the same anyway | 17:52 |
| fungi | https://opendev.org/opendev/project-config/src/branch/master/zuul.d/pipelines.yaml#L123-L132 | 17:52 |
| sean-k-mooney | fungi: we use gerrit acls to limit pushing to that ref to the release team member if i recall in most projects | 17:54 |
| fungi | sean-k-mooney: see my link above for sunbeam's acl as an example of an independent release project that does its own tagging outside the release managers | 17:55 |
| clarkb | dib too | 17:56 |
| sean-k-mooney | ya that whas i used to do for networking-ovs-dpdk | 17:56 |
| sean-k-mooney | https://opendev.org/openstack/project-config/src/branch/master/gerrit/acls/x/networking-ovs-dpdk.config#L14 | 17:56 |
| fungi | but yes, by default, openstack projects inherit an acl that only grants the tag pushing permission to the release managers | 17:57 |
| fungi | (and then the automation account used by the release management jobs belongs to that group) | 17:57 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!