Add Dockerfile UBI images for the Operator and ProxyRunner

[TomerFi]

This PR adds Dockerfile-based build and push processes for both the Operator and ProxyRunner images. These UBI-based images are passing OpenShift-Preflight tests by introducing a more secure base image.

[JAORMX]

@TomerFi I was more thinking about creating additional UBI images, not replacing the ones we have.

[JAORMX]

Perhaps we could have a <version>-ubi tag for the images instead?

[TomerFi]

I was more thinking about creating additional UBI images, not replacing the ones we have.

@JAORMX , I'm not sure I follow, do you want two build processes to exist simultaneously? One using ko.build and one using Dockerfile?

[JAORMX]

@TomerFi that's right

[TomerFi]

@JAORMX May I ask why?

[JAORMX]

@TomerFi because I would like to keep the ko builds which use a more minimal container image.

[dmartinol]

@TomerFi I was more thinking about creating additional UBI images, not replacing the ones we have.

driven by env vars or always 2 images per application? in the first case, what's the default?
BUILD_TOOL=ko Vs BUILD_TOOL=dockerfile

[JAORMX]

So, I was thinking of having:

ghcr.io/stacklok/toolhive-operator:v<version>      # ko-based image
ghcr.io/stacklok/toolhive-operator:v<version>-ubi  # UBI based image

How this happens is not super important to me. It could be another workflow that happens after the main build depending on the main release workflow. perhaps?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.23%. Comparing base (5805898) to head (9529a17).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2327      +/-   ##
==========================================
- Coverage   54.27%   54.23%   -0.04%     
==========================================
  Files         242      242              
  Lines       23446    23446              
==========================================
- Hits        12725    12716       -9     
- Misses       9506     9520      +14     
+ Partials     1215     1210       -5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jhrozek]

So, I was thinking of having:

ghcr.io/stacklok/toolhive-operator:v<version>      # ko-based image
ghcr.io/stacklok/toolhive-operator:v<version>-ubi  # UBI based image

How this happens is not super important to me. It could be another workflow that happens after the main build depending on the main release workflow. perhaps?

I like this scheme. As upstream, we should commit to maintaining UBI images - OpenShift is a very important downstream. But at the same I'd like us to keep the ko-based images as they are minimal, small and distroless.

As far as making it easier for clients to find and distinguish the images, perhaps we could add OCI image labels, e.g. dev.stacklok.toolhive.image-variant: UBI.

And I guess it would be nice to have a helm chart variable to easily switch between them.

(those can be another PR, just thinking out loud how to make life easier for consumers)

[TomerFi]

@JAORMX @jhrozek ^^

[jhrozek]

I think this look good, I wouldn't mind pushing this as long as it keeps moving you forward. I wasn't sure about the LDFLAGS invocation though and left a question.