FYI: @dcavalca, @salimma, @tdawson

Just had a quick look and it's introducing a massive change in kojira and I know that it had an impact on Fedora infra so clearly needs investigation before upgrading (see https://docs.pagure.org/koji/release_notes/release_notes_1.35/#kojira)

That can be reverted by setting the repo.auto=True property for all tags, I recommend doing that.

@tkopecek : reading https://docs.pagure.org/koji/repo_generation/ but that's not clear : do I understand correctly that kojira , in default setup on koji 1.35+ would not regen repo after a build ?
So what's the process : each time someone asks for a build, koji first kicks the regen-repo task for the build tag and only after would submit the real build ? From a user perspective that's adding more time to the build process so not sure what the real gain is ... or maybe It's not clear enough in doc.

And is the solution proposed by @ngompa above (using repo.auto=True in all build tags, so to be done manually) would restore previous functionality ? I wouldn't want to introduce a change that would break user experience so waiting for confirmation and/or doc fixes :)

@ngompa : had a quick look at this (while waiting for confirmation from @tkopecek or other koji folks) and have quickly upgraded https://cbs.stg.centos.org with 1.35.2 and haven't modified anything wrt tags and repo.auto=True

What I see is that it indeed kicks automatically a regen-repo task before a build (so before instead of after). Example for a simple scratch build (even a --scratch would kick an on-demand regen-repo) :

2229 build (infra10s-infra-common-el10s, time-1.9-24.el10.src.rpm): free
12229 build (infra10s-infra-common-el10s, time-1.9-24.el10.src.rpm): free -> open (kojid1.stg.centos.org)
  12230 waitrepo (infra10s-infra-common-el10s-build, ): free
  12230 waitrepo (infra10s-infra-common-el10s-build, ): free -> open (kojid1.stg.centos.org)
  12233 rebuildSRPM (noarch): free
  12230 waitrepo (infra10s-infra-common-el10s-build, ): open (kojid1.stg.centos.org) -> closed
  1 free  1 open  1 done  0 failed
  12233 rebuildSRPM (noarch): free -> open (kojid1.stg.centos.org)
  12233 rebuildSRPM (noarch): open (kojid1.stg.centos.org) -> closed
  0 free  1 open  2 done  0 failed
  12234 buildArch (time-1.9-24.el10s.src.rpm, x86_64): free
  12234 buildArch (time-1.9-24.el10s.src.rpm, x86_64): free -> open (kojid1.stg.centos.org)
  12234 buildArch (time-1.9-24.el10s.src.rpm, x86_64): open (kojid1.stg.centos.org) -> closed
  0 free  1 open  3 done  0 failed
12229 build (infra10s-infra-common-el10s, time-1.9-24.el10.src.rpm): open (kojid1.stg.centos.org) -> closed
  0 free  0 open  4 done  0 failed

While that doesn't seem a big issue per se, it's though adding some needed time, which would be a longer user experience when submitting a build.
I'll test with the repo.auto=True on same build tag and resubmit something to see if that's then reverting to previous user experience

Sorry, I was offline for some time. Anyway, you don't need to add repo.auto to buildtags. If repo doesn't exist before the build, it will be generated automatically as you see in your build task. For next build task this will be skipped if build was not triggered with --wait-repo or --wait-build which is not satisifed by current repo version. So, user experience would generally be better not worse as most of the repos are not needed and just thrown away.

repo.auto is meant for special cases (e.g. you want to consume build tag outside of build tasks (or even completely out of koji)), so there is no task which can query state / request repo regeneration). Of course, e.g. kiwi plugin consuming koji repos could be the case when it would be better as these urls are not recognizable to external repos (it is not the case of --use-buildroot-repo.

repo.auto is meant for special cases (e.g. you want to consume build tag outside of build tasks (or even completely out of koji)), so there is no task which can query state / request repo regeneration). Of course, e.g. kiwi plugin consuming koji repos could be the case when it would be better as these urls are not recognizable to external repos (it is not the case of --use-buildroot-repo.

This case is normal for CentOS SIGs, so yes we want this.

ack .. FWIW, I already updated .stg. instance and so have a clear path for the cbs.centos.org one.
Working on other items in the queue (like various openshift upgrades #1609) but I'll try to plumb that one eventually this week (but I need to announce downtime and I'll be on PTO / away some days so eventually week after to be sure)

Announced : https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/GXSZMF7AQBIUJGPFQELAHQ2IULX2KKGJ/

upgraded, closing