<!!image>
When there is a waitrepo before a task, we need the subsequent repoid to be updated to the latest, but in fact it is not

For example, in the following figure, the repoid used after waitrepo is 6557031, but before that, newrepo updated the repoid to 6557063
<!!image>
<!!image>

We hope that all repoids after waitrepo point to the latest version. Is there any way to do this? Thanks！

I think you may be seeing issue #4206. This is fixed by #4207, which is included in 1.35.2, though 1.35.2 has some other issues and we're working on a 1.35.3

Or I might be misreading you. I guess it depends on what you mean by "latest". If the issue isn't #4206, then perhaps you could give more detail?

If a tag changes, then at the beginning of the task there will be a waitrepo to update the repo, but the buildArch task following the waitrepo will use the previous repoid instead of the updated repoid of the waitrepo task.

The subtask will wait for the completion of the waitrepo task, and waitrepo will trigger the newrepo task. After the waitrepo task is completed, the next subtask should need to use the repoid after newrepo instead of continuing to use the original repoid, right?

I don't know if I didn't explain the problem clearly or if I misunderstood something. Thanks！

@mikem Looking forward to your reply

Thanks for clarifying!

What you are seeing is a side effect of #4284, which was fixed in 1.35.2 and should be landing in Fedora soon. The waitrepo subtask can choose an old repo during its first pass.

Please note that Koji does not guarantee that builds get the very latest repo. This would require significantly more regenerations, and it is generally not necessary. The build in your example got a repo that was only a few hours of date.

If you have a build that requires a repo with the very latest content, then you can pass --wait-repo to the build command to ask for that (this should work even without the fix for #4284). For more information on how Koji handles regens, see https://docs.pagure.org/koji/repo_generation/

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

Please continue any further discussion there.