haleyb | gmann: 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 branches | 15:52 |
---|---|---|
frickler | haleyb: I think this is much better than having different job names. cc config-core ^^ | 16:50 |
clarkb | I 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 ring | 16:51 |
haleyb | frickler: thanks for reviewing, like i mentioned, the alternative is to create even more definitions if we want them separate | 17: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 | |
gmann | haleyb: 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 itself | 19:55 |
haleyb | gmann: 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 |
haleyb | was trying to use the same names | 20:03 |
gmann | haleyb: ok. commented in this to use branch specific name for distro specific branch template https://review.opendev.org/c/openstack/charm-zuul-jobs/+/937479 | 20:07 |
gmann | I think that way it should work and it will help to maintain generic templates/jobs in generic way | 20:07 |
gmann | and it they can be defined in charms repo, you can easily modify if more distro version specific branches grow | 20:08 |
haleyb | gmann: the problem with changing names is we have to update all repos stable branches, which means probably hundreds of changes | 20:10 |
haleyb | my one zuul change fixes them all | 20:10 |
gmann | haleyb: 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 projects | 20:11 |
gmann | I 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 branches | 20:12 |
gmann | do you know how many repo has stable/jammy and stable/focal branches? | 20:13 |
haleyb | gmann: so only one hundred patches :( i'd rather merge the change i have, or modify it to have more jobs with regexes matching jammy, etc | 20:13 |
haleyb | i don't know exactly | 20:13 |
gmann | I do not see in these repo at least https://opendev.org/openstack/charms.openstack https://opendev.org/openstack/charm-aodh | 20:14 |
gmann | I 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-cluster | 20:19 |
gmann | not even 3rd partr | 20:20 |
haleyb | hmm, i thought there were more | 20:20 |
gmann | https://opendev.org/openstack/charm-trilio-data-mover | 20:20 |
gmann | haleyb: I think you might need only a few places to change | 20:20 |
gmann | because 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 |
gmann | easy 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 work | 20:23 |
haleyb | so 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 case | 20:25 |
gmann | haleyb: yeah generic charm template use same jobs but it differ in number of jobs or voting/n-v | 20:26 |
gmann | haleyb: 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 so | 20:28 |
gmann | maybe 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 needed | 20:30 |
haleyb | gmann: sounds good. I did just push an update to my other change, just haven't tested it yet | 20:32 |
gmann | haleyb: thanks | 20:33 |
gmann | haleyb: it seems that is working, stable/jammy run the jammy nodeset jobs now https://zuul.openstack.org/status?change=937195%2C8 | 20:47 |
gmann | haleyb: you can do same for pep8 also as you did for tox-cover | 20:47 |
haleyb | gmann: 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 work | 20:53 |
haleyb | so it runs both py3* and pep8, etc | 20:54 |
gmann | haleyb: 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 |
gmann | haleyb: commented two way in this, please check whihc one you prefer or easy https://review.opendev.org/c/openstack/charm-zuul-jobs/+/937479 | 21:05 |
haleyb | gmann: thanks, will try and update | 21:23 |
*** haleyb is now known as haleyb|out | 23:07 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!