Learn more about these different git repos.
Other Git URLs
We have a relatively complicated tag inheritance setup for our user's Koji tags:
<img alt="Screenshot_2021-03-26_14-46-52.png" src="/koji/issue/raw/files/d4b6d89cae8cfbf5ac07655306106c68e9ae9a824eaba6fce42135422ac80faf-Screenshot_2021-03-26_14-46-52.png" />
When we update the external repos assigned to centos8-defaults, we see that kojira does a regen-repo on it, as you would expect. However, user builds on mytag8-build will fail due to old metadata until we manually run a regen-repo on it. Is this supposed to happen, or is this something that kojira should be handling as well? Should we just script something to run regen-repo on all *-build tags after we update the external repos?
centos8-defaults
mytag8-build
*-build
Metadata Update from @tkopecek: - Custom field Size adjusted to None - Issue set to the milestone: 1.26
It looks weird - it definitely should trigger newRepo for mytag8-build. Isn't it just a repo with much lower priority, so it get regenerated later? You can check the kojira.log if it appears there. (and/or enable --queue-file to see repo regen ordering)
newRepo
No, I don't see it getting regenerated later either. I tried enabling --queue-file but it just seems to create a file with a single line: Tag Expired Score.
--queue-file
Tag Expired Score
So the situation is:
Are you sure that it was the external repo change that triggered the regen?
Are you seeing lines like Repo %i no longer current due to external repo change in kojira.log?
Repo %i no longer current due to external repo change
Yes, I do see lines like that, but I can't figure out what repo they refer to to see what it's really doing.
See what the current repo id for mytag8-build is (the taginfo command will show the number), and see if there is a kojira log line like that for that repo.
No, there's no line for mytag8-build in the kojira logs.
We have a script that basically does the same thing kojira's check_external_repos does now, so we may be launching regen-repos before kojira has a chance to. I've disabled our script to see if somehow that's interfering with kojira. Our script would regen centos8-defaults but not mytag8-build because it wasn't inheritance-aware.
check_external_repos
It seems it was actually our script that was regening centos8-defaults, without it kojira didn't do it on it's own. Could this be related to the fact that the external repos are in merge mode bare? I do see kojira working as it should on our Centos 7 tags, but those are set up with no inheritance and koji external repos.
bare
koji
@alexi Sorry for long silence. I've now time to look at it. Dumb question - is external repo checking enabled in config? (We don't do that by default because of potentially broken external repodata).
check_external_repos = True
Second thing - database needs to use UTC - otherwise time comparisons could be off.
Yes, check_external_repos is enabled and I'm running 1.24.1, which IIRC already has the UTC fixes.
Hmm, I've tried to replicate this concrete structure (with some local-served repo) and it works correctly. Maybe it is not related to external repo at all. Can you try to tag some build into mytag8-build directly and see if repo gets regenerated?
One case comes to my mind but that also seems unlikely - it mytag8-build is not used in any target, it will be ignored. But you've tried some builds against it so evidently it is not the case.
Yes, building a package to mytag8-build does regenerate the repo as it should.
The issue is when the external repos of centos8-defaults change, that gets regenerated but the tags that inherit it do not, so builds in mytag8-build fail because they're still looking for the old contents of the external repos.
What about "Check external repo ... for tag <id>" with same id from taginfo mytag8-build. Or more generally, is there that id at all refrenced anywhere in kojira.log with debug turned on?
Metadata Update from @tkopecek: - Issue set to the milestone: None (was: 1.26)
@alexi Is this solved somehow?
I'm not entirely sure because I added some external workarounds just in case it happened again. Since nobody else seems to have this issue, I guess we can close it.
Metadata Update from @alexi: - Issue close_status updated to: Dropped - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.