-
Notifications
You must be signed in to change notification settings - Fork 168
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
Add new build-cimage
command
#3128
base: main
Are you sure you want to change the base?
Conversation
Skipping CI for Draft Pull Request. |
One reason we need this wrapper is that 90% of what goes into a
I think where we want to go is probably to lower most of this into rpm-ostree as stable API, but it needs some thought. |
a4f32b1
to
4e6df71
Compare
Ah yes, had to add support for variants to build c9s |
4e6df71
to
16a0085
Compare
Rebased 🏄 |
This is a big step towards coreos#2685 I know there's a lot going on with the pipeline, and I don't want to conflict with all that work - but at the same time, in my opinion we are just too dependent on complex Jenkins flows and our bespoke "meta.json in S3". The core of CoreOS *is a container image* now. This new command adds an opinionated flow where one can do: ``` $ cosa init $ cosa build-cimage quay.io/cgwalters/ostest ``` And *that's it* - we do proper change detection, reading and writing from the remote container image. We don't do silly things like storing an `.ociarchive` in S3 when we have native registries available. Later, we can build on this and rework our disk images to derive from that container image, as coreos#2685 calls for. Also in the near term future, I think we can rework `cmd-build` such that it reuses this flow, but outputs to an `.ociarchive` instead. However, this code is going to need a bit more work to run in supermin.
16a0085
to
cc3b97c
Compare
Lifting draft on this...it could use some tests, but it does work today and greatly streamlines the flow of "I want to build a custom FCOS container image and push it to a registry". |
@cgwalters: PR needs rebase. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Depends #3127
This is a big step towards #2685
I know there's a lot going on with the pipeline, and I don't
want to conflict with all that work - but at the same time,
in my opinion we are just too dependent on complex Jenkins flows
and our bespoke "meta.json in S3".
The core of CoreOS is a container image now. This new command
adds an opinionated flow where one can do:
And that's it - we do proper change detection, reading and
writing from the remote container image. We don't do silly things
like storing an
.ociarchive
in S3 when we have native registriesavailable.
Later, we can build on this and rework our disk images to
derive from that container image, as #2685 calls for.
Also in the near term future, I think we can rework
cmd-build
such that it reuses this flow, but outputs to an
.ociarchive
instead.However, this code is going to need a bit more work to run in
supermin.