USHIFT-978 Building RPMs in container

[pmtk]

No description provided.

[ggiguash]

We're supporting RHEL 9 now in the main branch. Can we use RHEL9 containers / dependencies?

[pmtk]

This is because we use registry.ci.openshift.org/openshift/release:rhel-8-release-golang-1.19-openshift-4.13.
I see that rhel-9-release-golang-1.19-openshift-4.13 exists but it fails due to some certificates for rhel-9-for-x86_64-baseos-rpms repo.
Also, we're still using rhel-8-release-golang-1.19-openshift-4.13 in the CI jobs

[ggiguash]

Let's simplify the process by having one top-level target?

We already have 'make rpm' & 'make srpm' - can we add 'make rpm-podman'?

[pmtk]

Good idea, I'll just jam both building the image (if doesn't exist) and and this target into one

[ggiguash]

A general question: why would we want to build in a container if we have a devenv? Are you thinking to use this for building 4.12 branch on a RHEL9 machine for example?

[pmtk]

A general question: why would we want to build in a container if we have a devenv? Are you thinking to use this for building 4.12 branch on a RHEL9 machine for example?

We'll be able to use the same image CI uses, i.e. rhel8 (or 9) + go1.19 (which isn't available in the repos yet) and drop the workaround with installing two versions of Go, therefore fixing the microshift.spec to require right Go version (now we "require" 1.18, but it'll fail if 1.19 is not used).
That go1.1x workaround happened twice already so someday it'll happen again, so this would be one less thing to keep in mind.

I feel like QE's pipeline would benefit from being able to build in a container. From what I've seen recently, they only run configure-vm.sh to get that go1.19 side-installed, everything else is in the kickstart.
If we could get make iso containerized QE could drop dev-vm altogether most likely speeding up the procedure.
Same thing locally on laptop, build ISO without needing build vm (most likely with limited resources compared to the laptop).

[ggiguash]

Should we also add "go" invocation from the container and get rid of the "go" dependency dillema in the devenv all together? I mean, we could remove "go" installation from configure-vm.sh and have container builds executed by default for compilation and RPM creation.

[pmtk]

Should we also add "go" invocation from the container and get rid of the "go" dependency dillema in the devenv all together? I mean, we could remove "go" installation from configure-vm.sh and have container builds executed by default for compilation and RPM creation.

Maybe, we need to think about this.
I'm partial to leaving it as is because I build bins on laptop and copy on VM - I have Go on my laptop either way.
This would also be appreciated by devs with MacOS as Docker on Mac is actually docker on linux vm on Mac

[dhellmann]

Should we also add "go" invocation from the container and get rid of the "go" dependency dillema in the devenv all together? I mean, we could remove "go" installation from configure-vm.sh and have container builds executed by default for compilation and RPM creation.

Maybe, we need to think about this. I'm partial to leaving it as is because I build bins on laptop and copy on VM - I have Go on my laptop either way. This would also be appreciated by devs with MacOS as Docker on Mac is actually docker on linux vm on Mac

I may have a different workflow from others on the team. I set up a VM with all of the dependencies and do all of my work in that VM, so I install my editor, the go compiler, gopls, git, etc. I have heard others say they build elsewhere and copy files into the VM, or at least edit elsewhere.

[dhellmann]

This test is neat. I usually just let podman build run again and it takes a second to realize there is no change, but this looks quicker.

[ggiguash]

+1 on letting podman build figure out if there's a need to (re)build. It comes with a bonus of automatic rebuild when something changes in the Containerfile.

[ggiguash]

@pmtk , let's pull the Containerfile out of the hack directory.
We have a Dockerfile under packaging/images/openshift-ci directory. Since we're using a CI image, should we put the new file somewhere nearby?

[ggiguash]

Do we want to include a version in the image name, i.e. -t microshift-4.13-rpm-builder-rhel8-go1.19? I mean, we should be able to easily cross-compile from different branches on the same machine now, but images may be different.

[ggiguash]

Since we're building the container from make, can we simplify this by defining a variable in the Makefile and passiing it to the Containerfile?

Makefile:
GOLANG_CONTAINER=release:rhel-8-release-golang-1.19-openshift-4.13

podman build --env GOLANG_CONTAINER=$GOLANG_CONTAINER ...

Containerfile:
ENV GOLANG_CONTAINER
FROM registry.ci.openshift.org/openshift/$GOLANG_CONTAINER

[pmtk]

Following your suggestion, does microshift-builder:rhel-8-release-golang-1.19-openshift-4.13 sound good as an image name:tag?

[ggiguash]

I think so, because the CI image name/version is the main identifier for it.
Unless, of course, there's a limitation in docker not allowing to use that name as-is.

[pmtk]

Changed, PTAL

[ggiguash]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ggiguash, pmtk

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [ggiguash,pmtk]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@pmtk: all tests passed!

Full PR test history. Your PR dashboard.

Details

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. I understand the commands that are listed here.