Implement new haikudepotserver-server-graphics

[andponlin]

The purpose of this new container image is to service graphics requests such as;

• thumbnail production
• rendering HVIF to PNG
• image optimization

The -server-graphics is not intended to be world-facing but is only accessed by the HDS application server. The -server-graphics container image carries a small Java application server that mediates a number of common command line tools running on the host container.

This new service is being stood up because;

• Any vulnerabilities from the graphics command line tools will be ring-fenced to that container image.
• The main application server can be packaged as a much slimmer base image
• One of the graphics tools hvif2png is a Haiku build product. Building and packaging new versions of this tool is currently awkward and the binary build products for the target deploy architecture must be persisted into the HDS git repository.

The build of the image will probably be quite slow because it has to build the Haiku "buildtools" and then the "hvif2png" Jam target. It probably won't be something we want to do on each and every release of HDS.

[andponlin]

@nielx; This new GitHub action will build the haikudepotserver-server-graphics image. It is likely to take some time because it will be building a Haiku build product; for this reason it needs to build buildtools and then <build>hvif2png. We probably won't want to run this on each and every release so I am setting up a manual pipeline.

[andponlin]

@nielx ; I am introducing a new container image. I will later setup a K8S manifest for in the haiku/infrastructure repository to run this. Can you do a check on the GitHub pipeline for me as I'm not super familiar with that system.

[waddlesplash]

The build of the image will probably be quite slow because it has to build the Haiku "buildtools"

You don't need to build those if you are only building host tools; just configure with --host-only instead.

[andponlin]

The build of the image will probably be quite slow because it has to build the Haiku "buildtools"

You don't need to build those if you are only building host tools; just configure with --host-only instead.

Thanks @waddlesplash ; I will try that later as it may mean I can do a build on each release!

[andponlin]

The build of the image will probably be quite slow because it has to build the Haiku "buildtools"

You don't need to build those if you are only building host tools; just configure with --host-only instead.

Thanks @waddlesplash ; I will try that later as it may mean I can do a build on each release!

Yes it seems that on my laptop it takes around 6 mins to build, test and package the Dockerfile for the main application and around 4 minutes for the graphics server (including the hvif2png tool). So this means it will be viable to build and release on each tag. I've therefore merged the GH Actions scripts into one now so it will build and push both images. The GH action is untested but I have tested the builds through to K8S locally.