Install Sonobuoy in Dockerfile

[gerbsen]

Add Sonobuoy installation to Dockerfile with architecture support.

[mbuechse]

To be frank, I do hate this Dockerfile. It tries to install all dependencies, that is, for IaaS and KaaS alike, regardless of the eventual purpose. Would it be possible to supply sonobuoy via a mount? Otherwise, maybe the code can at least be shortened. With Ansible, we only need these lines (with curl):

    - name: Install Sonobuoy
      ansible.builtin.shell:
        curl -L {{ sonobuoy_tar_gz_url | trim | quote }} | tar xz sonobuoy
      args:
        chdir: "{{ ansible_user_dir}}/.local/bin/"
        creates: sonobuoy
      when: kaas | bool

Apparently, when curl can be used, there is no need to have three separate commands for downloading, extracting and removing a temporary file, and even the chmod seems to be unnecessary? Not sure if curl is available on a python-3.10 image (or whatever is used here), but I think it's worth a try.

[garloff]

To be frank, I do hate this Dockerfile. It tries to install all dependencies, that is, for IaaS and KaaS alike, regardless of the eventual purpose. Would it be possible to supply sonobuoy via a mount?

Are you objecting to building a one-size-fits-all container? What is your proposal? Two containers, one for IaaS and one for KaaS?
Currently, I think the size of the container is not yet exploding, so we can do the all-in-one for now, IMVHO.
The mount approach complicates things -- is that worth it?

[garloff]

Apparently, when curl can be used, there is no need to have three separate commands for downloading, extracting and removing a temporary file, and even the chmod seems to be unnecessary?

If things can be simplified, we should do that.

[gerbsen]

Are you objecting to building a one-size-fits-all container? What is your proposal? Two containers, one for IaaS and one for KaaS?
Currently, I think the size of the container is not yet exploding, so we can do the all-in-one for now, IMVHO.
The mount approach complicates things -- is that worth it?

I would also be against splitting it into multiple images. Currently, the Dockerfile is pretty straightforward, and even the sonobouy installation changes very little. Mounting an external binary into the image destroys, in my opinion, the point of multi-arch Docker images, which work “just like that” everywhere.

Thanks to the default build(x) parameters that I have now inserted, the image should even build for Windows.

[gerbsen]

I don't quite understand the GitHub checks stuff. Do you build the image with the CI? If I understand this correctly the image is only build once it's merged in main? Shouldn't this be also part if the branch/PR pipeline?

[mbuechse]

Approving under the assumption that it's been tested. My opinion about Docker hasn't changed, but I see myself outvoted, and that is fine.

[gerbsen]

@garloff Could you try to build/test this on your side?

[fkr]

While looking at this (and wanting to test the build on github), I found out that our workflow on github was broken by
r119557e - this PR fixes it. Once that is merged, we can rebase this PR and also test the build on github.

#1130

[fkr]

@gerbsen @mbuechse the github action for the docker build at least succeeds:

https://github.com/SovereignCloudStack/standards/actions/runs/22688276923/job/65776939473