many: allow copr:// URLs in --(force|extra-repo)#2461
Open
supakeen wants to merge 5 commits into
Open
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>
Member
Author
|
Going to undraft this, we can accept the slowness but I'd be interested in the discussion around it. |
brlane-rht
reviewed
Jul 17, 2026
| } | ||
|
|
||
| func fetchCoprProject(owner, project string) (*coprProject, error) { | ||
| apiURL := fmt.Sprintf("%s/api_3/project?ownername=%s&projectname=%s", |
Contributor
There was a problem hiding this comment.
Where is the API documented? Should be included in a comment somewhere in this file.
Contributor
|
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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.