ENT-13867: Added RHEL 8,9,10 support to build in container#2338
ENT-13867: Added RHEL 8,9,10 support to build in container#2338aleksandrychev wants to merge 1 commit into
Conversation
Ticket: ENT-13867 Signed-off-by: Ihor Aleksandrychiev <ihor.aleksandrychiev@northern.tech>
| @@ -0,0 +1,64 @@ | |||
| ARG BASE_IMAGE=rockylinux/rockylinux:9 | |||
| FROM ${BASE_IMAGE} | |||
There was a problem hiding this comment.
I don't think we should duplicate in a different way what we do in the build host setup. I would be fine with choosing either policy or scripts but not both.
There was a problem hiding this comment.
@craigcomstock I took https://github.com/cfengine/buildscripts/blob/master/container/Dockerfile.debian as reference, you mean install cfengine to install dependencies? If yes I'd like to have scripts rather than policies in this case to avoid chicken\egg problem when new platforms added.
There was a problem hiding this comment.
Using policy hasn't bought us so much and caused some trouble.
I would suggest we begin refactoring to stop using that policy and instead use scripts.
The goal was to make it "easier" to manage and this has not been the result.
Feel free to make a follow-up ticket for migrating away from policy to scripts for build host setup.
There was a problem hiding this comment.
@craigcomstock I took https://github.com/cfengine/buildscripts/blob/master/container/Dockerfile.debian as reference, you mean install cfengine to install dependencies? If yes I'd like to have scripts rather than policies in this case to avoid chicken\egg problem when new platforms added.
Also, there is a provision to build from source enough to bootstrap a new platform. If that doesn't work then we should fix it or remove it. It did work recently for rhel-10-arm fwiw. https://github.com/cfengine/buildscripts/blob/master/ci/setup-cfengine-build-host.sh#L217
| @@ -0,0 +1,64 @@ | |||
| ARG BASE_IMAGE=rockylinux/rockylinux:9 | |||
There was a problem hiding this comment.
ideally we will use these to build our packages so it seems we should use ubi/rhel images and not rocky.
There was a problem hiding this comment.
I looked into UBI, but its repos only contain a free redistributable subset of RHEL, and some packages we need to build (bison, flex, pam-devel, selinux-policy-devel) aren't included, see the public repo listing, e.g. no bison in the appstream: https://cdn-ubi.redhat.com/content/public/ubi/dist/ubi9/9/x86_64/appstream/os/Packages/b/ . Getting them on UBI requires RHEL entitlement certs inside the image build.
There was a problem hiding this comment.
That is correct. @olehermanse @nickanderson @vpodzime how would you suggest we proceed? Is the difference between rockylinux and rhel so little that we can rely on rockylinux to build?
There was a problem hiding this comment.
So many redhat issues. Most of our users are rhel proper. for basic building irocky might be ok but we need regular tests against rhel for real i think
There was a problem hiding this comment.
@craigcomstock short answer; I don't know. Long answer; we're splitting up building and testing, in theory, as long as we test on RHEL proper, I think it should be okay to build on something "similar enough".
There was a problem hiding this comment.
Is the difference between rockylinux and rhel so little that we can rely on rockylinux to build?
Why not CentOS Stream?
| - debian-11 | ||
| - debian-12 | ||
| - debian-13 | ||
| - rhel-8 |
There was a problem hiding this comment.
We might need Red Hat 7 as well
6 participants
Ticket: ENT-13867