#12392 koji 1.35: blocking a package from a tag does not seem to cause a newRepo
Closed: upstream a month ago by decathorpe. Opened a month ago by decathorpe.

  • Describe the issue

From what I can tell, package retirements are behaving a little weirdly since the upgrade to koji 1.35. The process that syncs the "blocked" status upon pushing a "dead.package" file works fine, I can see that the packages are getting blocked in the appropriate tags almost instantaneously.

However, blocking a package in a tag does not seem to be an event that's considered worthy of triggering a newRepo task. So if no build is done against that tag, then the repo is just never regenerated without the retired package (as far as I can tell).

Worse, there's no way to use the new koji wait-repo in this scenario.

In koji < 1.35, I was able to just do koji wait-repo f42-build to wait for the next newRepo to finish, and that would mean the retired package is no longer available in the repo.

Doing that in koji 1.35, the command exits immediately, since "repo already generated, what more do you want" or something like that. Similarly, specifying the --request flag for koji wait-repo doesn't seem to actually do anything if not paired with a specific --build <nvr> to wait for.

And since there's no way to tell it to "wait for this NVR to no longer be available", I don't think there's a way to watch for package removals right now.

  • When do you need this? (YYYY/MM/DD)

Unsure. Seems like either a bug or a limitation of the koji CLI.

  • When is this no longer needed or useful? (YYYY/MM/DD)

N/A

  • If we cannot complete your request, what is the impact?

Workarounds for different processes and / or scripts will be needed.


Doing that in koji 1.35, the command exits immediately, since "repo already generated, what more do you want" or something like that.

To clarify, koji wait-repo used to wait for the next newRepo task for the specified tag to finish, and not (again, as far as I can tell) exit immediately if the repo was already generated at some arbitrary point in the past.

Possibly this should be a upstream koji ticket?

Anyhow, we could mark the base build tags with repo.auto=True possibly, but it seems like perhaps koji should treat blocks as a reason to regen...

CC: @mikem

Yeah, for the behaviour change of koji wait-repo, I'll file a ticket upstream. I just added it as context why "no newRepo after block" is cumbersome right now.

I don't know how many config knobs there are, would "blocking a package from <tag> should cause newRepo for <tag and inheriting tags>" be an issue for upstream too?

The only real config knob we have here is setting a tag with 'repo.auto=true' to make koji "... regularly requests repos for such tags."

But thats not a real fix, just sort of a workaround... but it sounds like you found one already with upstream?

Should we just close this and track those upstream? Or do you think we should set repo.auto?

I think the workaround provided by upstream combined with the pending PR to make wait-repo behave more like it used to mostly solve this problem (at least for me). I'll go ahead and close this issue.

If problems persist, we can discuss turning on preemptive generation for some tags, but right now I don't think that's necessary. Thanks 🙏🏼

Metadata Update from @decathorpe:
- Issue close_status updated to: upstream
- Issue status updated to: Closed (was: Open)

a month ago

Log in to comment on this ticket.

Metadata