-
Notifications
You must be signed in to change notification settings - Fork 169
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
Insert generated image.json into the ostree commit #2811
Conversation
Skipping CI for Draft Pull Request. |
Can we hold this until we discuss #2685 with the larger group? I think this would be a good cabal topic. |
Prep for injecting `image.json` into the ostree commit. To make that meaningful, it has to be entirely independent of coreos-assembler. This bit is crucial for being able to do image builds in a manner independent of coreos-assembler's content, using solely the ostree commit as input.
cce3d1b
to
09d1636
Compare
09d1636
to
e179216
Compare
b5b5e6e
to
0c07d52
Compare
Note that this is just an incremental step - it still doesn't change in a fundamental way how the pipelines work. Yet 😄 |
So...personally, I think unit testing most of the coreos-assembler code in practice is not very useful. We have good integration tests that cover things.
cdec04e
to
782e94b
Compare
On one hand, it's great that our CI covers all the image variants. About 95% of the changes made here have 0% chance to break them, but this one actually does touch on all the weird corners. Cool to see CI successfully finding problems. On the other hand, holy cow is the code here a mess of shell script, heavily dynamic object-oriented python, and "script python". |
This is part of coreos/fedora-coreos-tracker#1151 Our generated disk images are largely just a "shell" around the egg of an ostree commit. There is almost nothing that lives in the disk image that isn't in the commit. (This is especially true now that a preparatory commit previous to this moved the *content* of our static `grub.cfg` into `image.json`) In the original coreos-assembler design I'd tried to cleanly separate builds of the ostree from disk image builds, but also support linking them together (with matching version numbers, etc.) The separate `image.yaml` was part of this. This...mostly worked. This change furthers that separation by having image builds input from *just the ostree commit*. Crucially we would no longer need the config git repository to perform an image build. And this in turn unlocks truly better separating ostree builds from disk image builds in the pipeline *and* supporting downstream tooling generating disk images from custom containers. One neat thing here is we will finally fix a longstanding issue where coreos-assembler fails when just the `image.yaml` changes: Closes: coreos#972
782e94b
to
089f9cd
Compare
/retest |
1 similar comment
/retest |
OK, got a green jenkins run here 🎉 ! The RHCOS failures are unrelated github ratelimits I think, will do another retry later. |
/retest |
OK so...while this isn't directly blocking anything at the moment, I'd like to make forward progress on this too. |
This looks ok to me; I'd like to do some sanity tests that the affected artifacts build successfully. Specifically the ppc64le build; @ravanelli do you have some cycles to test this PR in a ppc64le setting? I'll try to get a ppc64le machine from Beaker, too, so that I can try testing it. |
I should have realized that all the affected artifacts are already built as part of the CI jobs, so my local testing is kind of moot. Still proceeding with some ppc64le testing |
I grabbed a BM ppc64le system from Beaker and built this PR into a But when I booted the FCOS build initially, I didn't see I did see the layer in the
Even more bizarre, if I repeated
I did |
Isn't it just that you had an extra
|
OK I know there's some hesitancy on this but I think it's going to work and not break anything 😄 If it does, we can revert and/or use the stable cosa without much harm. |
Depends #2806
Serialize
grub-script
literally into image.jsonPrep for injecting
image.json
into the ostree commit. To makethat meaningful, it has to be entirely independent of coreos-assembler.
This bit is crucial for being able to do image builds in a manner
independent of coreos-assembler's content, using solely the ostree
commit as input.
Insert generated image.json into the ostree commit
This is part of coreos/fedora-coreos-tracker#1151
Our generated disk images are largely just a "shell" around the egg
of an ostree commit. There is almost nothing that lives
in the disk image that isn't in the commit.
(This is especially true now that a preparatory commit previous to
this moved the content of our static
grub.cfg
intoimage.json
)In the original coreos-assembler design I'd tried to cleanly
separate builds of the ostree from disk image builds, but also
support linking them together (with matching version numbers, etc.)
The separate
image.yaml
was part of this. This...mostly worked.This change furthers that separation by having image builds input from
just the ostree commit. Crucially we would no longer need the config
git repository to perform an image build.
And this in turn unlocks truly better separating ostree builds from
disk image builds in the pipeline and supporting
downstream tooling generating disk images from custom containers.
One neat thing here is we will finally fix a longstanding issue
where coreos-assembler fails when just the
image.yaml
changes:Closes: #972