Add a Dockerfile.buildroot #730
Conversation
|
xref https://github.com/openshift/release/blob/39000c1cacd39fc58381dae12a88d23866061a4d/projects/libpod/libpod.yaml#L28 |
|
One thing I'd like to do next is cache the Rust crates used by rpm-ostree somehow in this. Maybe also just cache some more of the top crates too? |
See coreos/coreos-assembler#730 - Skip installing deps, hooray! - Also skip the C test suite for now because of the linked fuse-overlayfs issue
We've talked before about how cosa isn't useful for people developing on e.g. rpm-ostree; this is a primary reason I personally use cosa via installing it inside my personal toolbox container. This PR implements something talked about before; we add a "buildroot" container (e.g. `quay.io/coreos-assembler/coreos-buildroot:latest`) that is basically `yum builddep` for the parts we care about. The main reason I want to do this right now is I am working on using cosa in rpm-ostree's CI, and having an up-to-date "buildroot" container with the dependencies pre-installed will help a lot with that. I ran into issues trying to use cosa as a base and do the `yum builddep` dynamically because of the `USER builder` directive; Prow isn't expecting that. Another reason to do this is that in the future I'd like to add first-class support to cosa for e.g. `ln -s /path/to/ostree overrides/src` and cosa would take care of building a layer (or RPM?) from that source.
|
📞 ? |
jlebon
left a comment
jlebon
left a comment
There was a problem hiding this comment.
I'm not completely up to date on the latest CI initiatives yet, but this patch looks good to me overall. Giving @dustymabe a final chance to take a look before merging.
|
This is a dependency for coreos/rpm-ostree#1893 |
|
Definitely looking for feedback about the "Prow as merge bot" push in particular of course! |
Do you mean openshift/release#4900 ? 4880 is closed Honestly I'm not sure about using COSA (or rather the COSA container) as a develop/test platform for other projects. It might be convenient to do so, but just not sure it's the right thing to do. That being said, I'm not going to block progress (merge away), but would be interested in what other people think. |
|
OK, merging. We have some followup discussion to have around where this is built - I am planning to use api.ci since I think it's more flexible than the Quay buildsystem, and having it there will naturally mesh with running other infrastructure in api.ci. |
Currently we have an `rhcos` namespace; automation of that was submitted in openshift#1969 but never merged (I may try to revive that). Since then, the Fedora CoreOS and RHEL CoreOS teams are unifying more organizationally. FCOS uses a lot of Fedora infrastructure, RHCOS uses RHT-internal stuff plus api.ci. I think it makes sense to blur these lines more by having a `coreos` project that can contain infrastructure used by both teams; this would be in addition to the FCOS use of CentOS CI. One specific thing I plan to add here is a "buildroot": coreos/coreos-assembler#730 That would work similarly to what libpod is doing. This is prep for more use of Prow by the CoreOS group. On the topic of Prow, one thing I'd like to investigate again is making use of [GCP nested virt](https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances) for CI. Either DPTP would expand the cluster with machines set up that way, or we'd stand up a new cluster to do it but also partially owned by DPTP with e.g. secrets sync'd across.
See coreos/coreos-assembler#730 - Skip installing deps, hooray! - Also skip the C test suite for now because of the linked fuse-overlayfs issue
See coreos/coreos-assembler#730 - Skip installing deps, hooray! - Also skip the C test suite for now because of the linked fuse-overlayfs issue
See coreos/coreos-assembler#730 - Skip installing deps, hooray! - Also skip the C test suite for now because of the linked fuse-overlayfs issue
This is used by our OpenShift Prow job; we use the cosa buildroot container: coreos/coreos-assembler#730 And using `yum` at all means we can flake on fetching rpm metadata.
This is used by our OpenShift Prow job; we use the cosa buildroot container: coreos/coreos-assembler#730 And using `yum` at all means we can flake on fetching rpm metadata.
3 participants
We've talked before about how cosa isn't useful for people
developing on e.g. rpm-ostree; this is a primary reason I personally
use cosa via installing it inside my personal toolbox container.
This PR implements something talked about before; we add a
"buildroot" container (e.g.
quay.io/coreos-assembler/coreos-buildroot:latest)that is basically
yum builddepfor the parts we care about.The main reason I want to do this right now is I am working
on using cosa in rpm-ostree's CI, and having an up-to-date "buildroot"
container with the dependencies pre-installed will help a lot with that.
I ran into issues trying to use cosa as a base and do the
yum builddepdynamically because of the
USER builderdirective; Prow isn't expecting that.Another reason to do this is that in the future I'd like to
add first-class support to cosa for e.g.
ln -s /path/to/ostree overrides/srcand cosa would take care of building a layer (or RPM?) from that
source.