Skip to content
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

Merged
merged 7 commits into from
Jan 7, 2025

Conversation

croissanne
Copy link
Member

@croissanne croissanne commented Dec 17, 2024

This required accepting (snapshotted) payload and custom repositories by uuid.

@croissanne
Copy link
Member Author

/jira-epic HMS-4930

@schutzbot schutzbot changed the title v1: support specifying snapshotted, payload and custom repositories by uuid v1: support specifying snapshotted, payload and custom repositories by uuid (HMS-5212) Dec 17, 2024
@croissanne croissanne changed the title v1: support specifying snapshotted, payload and custom repositories by uuid (HMS-5212) v1: support user uploaded content Dec 17, 2024
@croissanne croissanne changed the title v1: support user uploaded content v1: support user uploaded content (HMS-5212) Dec 17, 2024
Copy link

codecov bot commented Dec 17, 2024

Codecov Report

Attention: Patch coverage is 56.80751% with 92 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
internal/v1/handler_compose_image.go 52.70% 45 Missing and 25 partials ⚠️
internal/clients/content_sources/client.go 54.16% 16 Missing and 6 partials ⚠️
Files with missing lines Coverage Δ
internal/v1/api.go 49.02% <ø> (ø)
internal/v1/mocks/content_sources.go 75.58% <100.00%> (+1.03%) ⬆️
internal/clients/content_sources/client.go 60.18% <54.16%> (-7.01%) ⬇️
internal/v1/handler_compose_image.go 64.73% <52.70%> (-1.14%) ⬇️

@croissanne croissanne marked this pull request as ready for review December 17, 2024 16:10
@croissanne croissanne force-pushed the repos-by-ids branch 2 times, most recently from 5f6659d to 55862c7 Compare December 17, 2024 16:32
lzap
lzap previously approved these changes Jan 3, 2025
Copy link
Collaborator

@lzap lzap left a 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
}
Copy link
Collaborator

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.

Copy link
Member Author

@croissanne croissanne Jan 6, 2025

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.

Copy link
Collaborator

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.

@croissanne croissanne force-pushed the repos-by-ids branch 3 times, most recently from ed706a6 to 3c50a0e Compare January 3, 2025 10:44
@lzap
Copy link
Collaborator

lzap commented Jan 3, 2025

Not sure if you meant to fix those nitpicks, I see no changes. It needs a rebase once again FYI.

@croissanne
Copy link
Member Author

Not sure if you meant to fix those nitpicks, I see no changes. It needs a rebase once again FYI.

still working on the integration test

@croissanne croissanne force-pushed the repos-by-ids branch 10 times, most recently from 4e53f5f to a7c5d9b Compare January 7, 2025 09:26
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.
@lzap lzap merged commit 329ee50 into osbuild:main Jan 7, 2025
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants