@mikem some concerns/question in the PR. I'll fix tests when we agree on code.

Another option not mentioned there is symlink to original repodata instead of hardlinking content

Unfortunately, seeing this actually coded up, this seems like the wrong approach.

Repos are key to the way builds happen and having this odd code path buried in a plugin risks future divergence. The way that we create repos needs to be systematic.

Calling repo_init is potentially slow. It looks like this is pretty fast in Fedora currently, but in Brew we often see newRepo tasks that take several minutes before firing off their first createrepo subtask.

I'm proposing an alternate approach:

• the sidetag plugin should trigger a regen or otherwise convince kojira to do so promptly
• the regular newRepo code path should check to see if the oldrepo it is considering actually has the same content (pkglist, blocklist, comps) on a per-arch basis. If identical (and not maven enabled, or with external repos, or otherwise ineligible), it should bypass the normal createrepo and instead perform the repodata copy
• this both of these should be configurable features, and off by default at least for now
• copy the repo repodata. no symlinks/hardlinks. it's not a ton of data.
• record that this happened somehow. perhaps we write an extra info file.

The above is separable and can be done in two parts

• triggering newRepo when creating side tag
• optimization in newRepo when oldrepo has the same content

Casually looking in koji.fp.o, it looks like in the common case that kojira is triggering the newRepo task fairly quickly, but I imagine there are times when there is a backlog and this becomes minutes slower. Triggering in the plugin might not help the common case much, but it could help the backlog case quite a bit.

Triggering could mean creating the newRepo task directly (not 100% ideal, but probably ok for now), or getting a signal to kojira. If we don't want to invent a new way to do that, we could just trigger a waitrepo task which kojira now looks for.

The second optimization part might apply to other repo regens as well. Could be a significant overall improvement.

Makes sense - I've updated this PR to just trigger newRepo. I'll create new one for newRepo optimization.

• PR #3842

This one looks fine. I wonder if the return field should be named repo_task_id

This doesn't capture kojira settings debuginfo_tags, source_tags, and separate_source_tags. I guess that is ok for now, and kojira is due for an overhaul anyway. We do at least have the with_debuginfo field in tag.extra that overlaps with debuginfo_tags setting.

:thumbsup:

Commit 369e816b fixes this pull-request

repo_json = koji.load_json(f'{src_repodata}/repo.json')
repo_json['cloned_from_repo_id'] = src_repo_id
koji.dump_json(f'{dst_repodata}/repo.json', repo_json, indent=2

This code from copy_arch_repo is using the wrong location for repo.json. This file lives in the main repo directory, and is not stored per arch. So this bit doesn't fit in this function.

This exposes a larger issue -- we don't have a mechanism for the builder to update repo.json, so we'll need to add one. Perhaps this can be added to the repoDone call.