Learn more about these different git repos.
Other Git URLs
Pungi creates a YUM repo for each variant. It might be convenient to create a .repo file for these repos.
.repo
(This is an internal request RCMPROJ-5514.)
Would the .repo file contain an absolute URL? In that case it's out of scope of pungi. Maybe we should move it to compose-tools as compose-create-repo-file(s) <compose> <baseurl>
Looks like pungi/phases/osbs.py is doing something like this already. The .repo files from that osbs phase are in the work dir, so I'm not sure what the stability guarantee is there. (I assume the work file/directory layout is considered internal to Pungi, and other tools should not rely on that layout?)
pungi/phases/osbs.py
work
You are correct that the file in work is really just an implementation detail. The main problem with providing the file is that while we know where the compose is created, it may very well be moved after finishing. That would invalidate all .repo files.
Fedora does not move the composes as a whole, but internally there are workflows for moving the compose to another location once it passes some level of testing.
With regards to paths changing, for the OSBS use case, this is irrelevant because the image build will run before the compose finishes so there's no chance it will move in that time. But for the general use case of having a repo file, both internally and in fedora we move composes on occasion. Internally we use compose-promote (distill/pungi-utils) to move a compose. If compose-promote was updated to take into account the similar translate_path logic, and was expanded to be able to move across filesystems, it might be able to include an update_repofiles task to update those files while it's moved.
I'm liking @dmach's idea of a separate utilitycompose-create-repo-file. I have some code that can do this at https://github.com/red-hat-storage/bucko/blob/master/bucko/repo_compose.py
compose-create-repo-file
It's been a while since this issue was filed, and nothing happened here. I'm going to close this issue to clear the backlog.
Metadata Update from @lsedlar: - Issue close_status updated to: Insufficient data - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.