-
Notifications
You must be signed in to change notification settings - Fork 44
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
v1: support user uploaded content (HMS-5212) #1443
Conversation
/jira-epic HMS-4930 |
Codecov ReportAttention: Patch coverage is
|
bde9dcf
to
13284a1
Compare
5f6659d
to
55862c7
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.
LGTM I haven’t tried this myself tho.
} | ||
} | ||
|
||
return result, nil | ||
} |
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.
Not huge fan of putting so much logic into a HTTP client. Ideally, the whole client.go
could be auto-generated from OpenAPI, I remember we sligthly discussed it on Slack and I forgot what was the reason not to generate it. But there is a lot of boiler plate that could be generated.
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.
Currently it's a balance between putting stuff in v1
and clients
. We could probably autogenerate some stuff and then have some logic around it in clients
, as v1
is pretty big.
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.
Yeah not the right time and place, but I am all for generating as much as possible for OpenAPI clients. The generator we use supports selective generation, only endpoints we are interested in can be generated.
ed706a6
to
3c50a0e
Compare
Not sure if you meant to fix those nitpicks, I see no changes. It needs a rebase once again FYI. |
3c50a0e
to
46a42a7
Compare
still working on the integration test |
4e53f5f
to
a7c5d9b
Compare
The upload origin refers to repositories created from content the user uploaded directly.
This offloads most of the logic to the content sources client. This paves the way for supporting repositories with an upload origin, which only have a repository ID available. Furthermore this will allow us to treat the external origin repositories in the same way, based on ID, whilst only using the URLs for the red hat repositories.
This allows users to specify repository UUIDs from the content sources service instead of baseurls when using snapshots.
Uses content sources to fill in any data that's not already specified.
Uses content sources to fill in any data that's not already specified.
A small mock is needed, it can just return empty data, but image builder now needs content sources to do a simple compose to check if any of the repositories are defined in content sources.
a7c5d9b
to
72bf558
Compare
This required accepting (snapshotted) payload and custom repositories by uuid.