many: allow copr:// URLs in --(force|extra-repo)#2461
Conversation
Let's be consistent and rename override to force in manifestgen and all callers of it. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Allow for the appending of repositories on a reporegistry. Also offer a useful ListArches function to get all the available arches for a distribution. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
We had a comment talking about moving this to the reporegistry. I've implemented it in a slightly different way in the previous commit but let's make use of it. The behavior is covered by tests already. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Include the distribution and architecture in calls to `parseRepoURLs` and pass them along. This means that `parseRepoURLs` gets called a bunch more but that's OK they currently contain single strings. This is necessary because in the future we want to support (for example) COPR lookups where we'll be using the COPR API to get the correct information to create a `RepoConfig`. For this we need access to the additional information to find the correct repository for a given image type. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
Allow passing of `copr://@owner/project` URLs to `--(force|extra)-repo`. We look up the COPR chroot necessary through the distro/arch that we pass along. We rename some distro names as they use different chroot names from our internal names (`centos`) and for RHEL we go from specific-to-RHEL to EPEL. Signed-off-by: Simon de Vlieger <cmdr@supakeen.com>
|
Going to undraft this, we can accept the slowness but I'd be interested in the discussion around it. |
| } | ||
|
|
||
| func fetchCoprProject(owner, project string) (*coprProject, error) { | ||
| apiURL := fmt.Sprintf("%s/api_3/project?ownername=%s&projectname=%s", |
There was a problem hiding this comment.
Where is the API documented? Should be included in a comment somewhere in this file.
|
I'm a bit on the fence. Mostly because it's adding complexity. But running really slow I think is a show-stopper, at the least I think it needs to only be run once it has all the needed info. But also, what does this really gain? Looking up copr repos is pretty easy already, the use probably already knows which arch/distro they want and can pull the baseurl from copr and pass it to |
Looking up COPR repo's isn't that easy; to give you a workflow: I want to build c10s and all Fedora's for aarch64 and x86_64 with some additional packages from several COPR repositories to test a new systemd/uboot/whatever. If you try to go through those steps in your head of what you need to do:
Then for each arch/distro combination fill in the values yourself. You spend a lot of time on it. When doing a single COPR for a single distro/arch sure that's straightforward enough; but there's also no real reason not to make it easier to do that. Same as I want to make it easier to say 'build an image with this Bodhi update enabled' which is super useful during test/freeze periods in Fedora. If it wasn't so slow, I think a user-friendly feature like this would probably be not controversial, same goes for the Bodhi-variant :) I agree that with the current implementation it's not worth it because it slows down the way we do repositories so badly. But now that this PR is open, it does show a problem in how we do our repository registry and what effect it has so we'll have to discuss that first 🙁 |
2 participants
A long time ago we had discussed making it easier to pass certain types of repositories into
image-builder. A super common use case is to want to build with a package from a COPR repository.This PR implements just that. When
--(force|extra)-repo copr://@osbuild/osbuildis passed the COPR API is used to look up the corresponding chroot (based on the distro/arch combination) and a repoconfig is generated from it and used.The implementation here is slow to the point of it being barely usable when a COPR URL is passed. This is because we look up COPR things for the distro*arch combination for all distros when newRegistryImpl is called. This could be addressed a few different ways and I'd like input.
parseRepoURLs(I tested this; it's way faster).Which one has preference? The comment that is there seems to hint at the latter but it also feels kinda funky to deal with anything else but
RepoConf.All of this boils down to us needing the reporegistry to determine what we can build.