Wednesday, 2024-12-11

haleybgmann: does https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/937194 look better for fixing charm pep8/cover jobs? Or i could try creating separate definitions to just match those branches15:52
fricklerhaleyb: I think this is much better than having different job names. cc config-core ^^16:50
clarkbI think that works particularly since the branch naming scheme is directly tied to the node choice it is easy ot understand without a second decoder ring16:51
haleybfrickler: thanks for reviewing, like i mentioned, the alternative is to create even more definitions if we want them separate17:04
-opendevstatus- NOTICE: Gerrit will undergo a short restart to pick up some bugfixes for the 3.10 release that we upgraded to.19:25
gmannhaleyb: i am fine with that but one question I posted ion gerrit also. is stable/<distro version> branches common way in charms? I am wondering if it is and it can grow more in future then it make sense for charm not to use the generic template in those charm specific branches and you can define and use job from charms repo itself19:55
haleybgmann: jamespage can maybe give a more definitive answer, but the openstack-specific charms follow a stable/<openstack name> pattern, ones that apply to more than openstack follow a stable/<distro version> pattern. If you want to wait until he weighs-in i can add him and felipe to the change. I did try and do this in the charms repo but failed miserably - https://review.opendev.org/c/openstack/charm-zuul-jobs/+/937479 since i 20:03
haleybwas trying to use the same names20:03
gmannhaleyb: ok. commented in this to use branch specific name for distro specific branch template https://review.opendev.org/c/openstack/charm-zuul-jobs/+/93747920:07
gmannI think that way it should work and it will help to maintain generic templates/jobs in generic way20:07
gmannand it they can be defined in charms repo, you can easily modify if more distro version specific branches grow 20:08
haleybgmann: the problem with changing names is we have to update all repos stable branches, which means probably hundreds of changes20:10
haleybmy one zuul change fixes them all20:10
gmannhaleyb: not all stable branches, it only need stable/focal and atble/jammy to change and rest all openstack way named stable branches will be handled by the generic templates like it does for all other projects20:11
gmannI mean, 1. use generic template for all stable/<openstack name way> 2. use distro specific template (which can be defined in charms repo only) in distro specific stable branches20:12
gmanndo you know how many repo has stable/jammy and stable/focal  branches?20:13
haleybgmann: so only one hundred patches :( i'd rather merge the change i have, or modify it to have more jobs with regexes matching jammy, etc20:13
haleybi don't know exactly20:13
gmannI do not see in these repo at least https://opendev.org/openstack/charms.openstack https://opendev.org/openstack/charm-aodh20:14
gmannI am not finding any of the openstack project charms repo have these branches, ONly one I find is https://opendev.org/openstack/charm-mysql-innodb-cluster20:19
gmannnot even 3rd partr20:20
haleybhmm, i thought there were more20:20
gmannhttps://opendev.org/openstack/charm-trilio-data-mover20:20
gmannhaleyb: I think you might need only a few places to change20:20
gmannbecause another issue I am seeing with charms stable branches is they have version specific branches also stable/18.0 etc and if we end up accommodating those in generic template then it will make them more complex 20:21
gmanneasy way is to use/keep generic template/jobs for generic stable branches (which every openstack projects has) and if project specific stable branches (like stable/bug#|distro-version|version) then they can defined their own jobs/templste if generic one does not work20:23
haleybso there is also charm-hacluster, charm-mysql-router, charm-rabbitmq-server, could be more. i can understand keeping it separate if possible, although there is already a few in openstack-zuul-jobs for charms just not this case20:25
gmannhaleyb: yeah generic charm template use same jobs but it differ in number of jobs or voting/n-v20:26
gmannhaleyb: I am not against of merging 937194 to unblock the gate but it will be better if charms repo can handle these charms specific stable branch testing. I think same we did when some projects used to have bug specific stable branches or so20:28
gmannmaybe jamespage can tell us how many repo need updates for distro-version specific stable branches and name and then we can handle these jobs things in more better way (as suggested above) ion its own time if there are more work needed20:30
haleybgmann: sounds good. I did just push an update to my other change, just haven't tested it yet20:32
gmannhaleyb: thanks20:33
gmannhaleyb: it seems that is working, stable/jammy run the jammy nodeset jobs now https://zuul.openstack.org/status?change=937195%2C820:47
gmannhaleyb: you can do same for pep8 also as you did for tox-cover20:47
haleybgmann: i did but not sure it's quite right. it currently uses openstack-python3-charm-jobs (defined in openstack-zuul-jobs), not pep8 directly. so will need more work20:53
haleybso it runs both py3* and pep8, etc20:54
gmannhaleyb: right, we need to replace the generic template to jammy specific template https://review.opendev.org/c/openstack/charm-zuul-jobs/+/937479/comment/53a19ca4_d6ffb344/21:02
gmannhaleyb: commented two way in this, please check whihc one you prefer or easy https://review.opendev.org/c/openstack/charm-zuul-jobs/+/93747921:05
haleybgmann: thanks, will try and update21:23
*** haleyb is now known as haleyb|out23:07

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!