average waitrepo over the past month is seven minutes.

koji=> select count(id), avg(start_time-create_time) as wait, avg(completion_time-create_time) as total from task where create_time > '04-01-23' and method='waitrepo';
 count |      wait      |      total      
-------+----------------+-----------------
  2145 | 00:00:17.57357 | 00:07:06.007069
(1 row)

The initial repo creation for the side tag is already made more efficient by recycling the parent repo. It is used as the basis for createrepo --update.

The trouble with your suggestion is that the chain-build command is not specific to side tags

The trouble with your suggestion is that the chain-build command is not specific to side tags

I don't understand what you are saying. Does a chain-build in a regular tag also wait for the repo first? What is it waiting for exactly?

Does a chain-build in a regular tag also wait for the repo first?

The difference is that the regular tag probably already has a repo. With a brand new side tag, the repo has yet to be created.

This initial wait isn't actually coming from the chain-build handler. Look at examples (e.g. https://koji.fedoraproject.org/koji/taskinfo?taskID=100745126) and you'll see that first waitrepo you're complaining about is a subtask of the build task. This happens when there is no repo for the build tag.

i.e. this would happen even with a non-chain build on a new side tag

The difference is that the regular tag probably already has a repo. With a brand new side tag, the repo has yet to be created.

That was my assumption as well. Hence I don't understand at all what you mean by "The trouble with your suggestion is that the chain-build command is not specific to side tags" -- my suggestion is not related to the chain-build command specifically, it is merely used as an example of the workflow that currently takes longer than necessary. An example with "build" rather than "chain-build" would serve the same way.

My suggestion is that when a side tag is created, the parent repository would be immediately linked/etc. and there would be no initial waiterepo necessary for the first build in that side tag.

Ah, this initially read to me as suggesting a modification of the behavior at the point of the waitrepo inside chain-build.

So, then...

A brand new side tag should in principle generate the same repo content as the base tag. A notable exception is the debuginfo flag.

I guess the createSideTag call could, at least optionally, be altered to create a bootstrap repo by copying. We'd need to be careful about how this is done and recorded, but sure.

Some notes:
- deal correctly with debuginfo-enabled repos
- ignore maven repos

Commit 369e816b fixes this issue

Commit fdedf093 relates to this ticket

Commit bb9d86db relates to this ticket

Thanks for looking into this, @tkopecek!

Hmm, that was autoclosed - there is also another PR needed #3842 but it should be part of same release.

Commit c3c0a6a1 fixes this issue

Commit c0c1f3c3 relates to this ticket

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/3808

Please continue any further discussion there.