-
Notifications
You must be signed in to change notification settings - Fork 106
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cloudapi: Add /distributions/ to cloudapi #4336
base: main
Are you sure you want to change the base?
Conversation
46ab488
to
5f16411
Compare
I'm thinking I want to extend this to return more, so converting to draft for now. |
5f16411
to
a316c2a
Compare
a316c2a
to
e8ae6ac
Compare
e8ae6ac
to
388076f
Compare
bba8569
to
0e142d2
Compare
e798fd1
to
85d1c15
Compare
This PR is stale because it has been open 30 days with no activity. Remove "Stale" label or comment or this will be closed in 7 days. |
85d1c15
to
d15d3c4
Compare
d15d3c4
to
9274be2
Compare
9274be2
to
7372cb0
Compare
This adds an actual repository json file for the test-disro. Without this the repo.ListDistros() function doesn't return any actual distros. Also includes a test to make sure 1 or more repos are loaded. Related: RHEL-60133
7372cb0
to
4328ef8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the change.
I don't understand the reason behind returning the full repository configuration for each distro/arch/image_type combination from this endpoint. I think that I'm missing the bigger picture behind this change, especially since the linked Jira task talks only about listing the matrix of supported distro:arch:image_type and nothing about repositories.
In addition to that, The summary of the PR is in contradiction to what this PR does - adding only /distributions/
endpoint and not /distributions/{arch}
.
Lastly, I'm not sure if it is a good practice for API to use values as object property names in the returned JSON. IOW, the implemented approach vs. to return a flattened array of objects such as:
[
{
"distro": "test-distro-1",
"arch": "test_arch",
"image_types": [
"test_type"
]
},
...
]
I'm trying to remember why I included the actual repo data, and I think it was because we've had some questions about exactly what repos are being used for a build and no way to query that info. It's useful info, and easily available, so I included it. As for the openapi layout, I couldn't figure out any other way to do it and have variable named keys. The reason for that is that it makes more sense to process the output using keys than it is to have to search through all the results for the distro+arch. The output from this will be used with composer-cli in order to let the user explore what's available to use for the builds, so more detail is better. |
This adds support for listing all of the supported distributions, their arches, the image types, and their repository details. This returns 3 nested json objects. The keys for the first layer are the distribution names. The 2nd layer's keys are the architectures supported by that distribution, and the 3rd layer's keys are the image types supported by that distribution:architecture pair. The value of the 3rd layer is the repository information. Resolves: RHEL-60133
Related: RHEL-60133
4328ef8
to
93d0f98
Compare
This pull request includes: