add configuration and workflow for container build

[twsearle]

Description

We need to update the version of the atlas library used by the CI. To do this independently of JCSDA we need to be able to build our own container containing the base image for the ci to run.

This change is the first of 4 small changes:

1. merge this change and build the container, tagged at this version (using atlas 0.37)
2. update the ci to use the new container.
3. create a container at atlas 0.38.1
4. update the ci as part of merging Feature/update atlas 0.38.1 #107 to use the latest container version.

This container is based on the one found in jopa-containers. There were a few fixes needed (hdf5 has moved url slightly, and I removed some libraries and lfric/um packages to speed up and shrink down the container size).

Issues

/issues/109

Impact

Expected impact on downstream repositories or workflows:

• none expected

Testing

• It is difficult to test adding a github workflow. The best I can do is merge and run an almost identical change on my fork:
  https://github.com/twsearle/orca-jedi/actions/runs/10151112706
• I followed this up with implementing ci using this build to check it works here:
  https://github.com/twsearle/orca-jedi/actions/runs/10161039329/job/28098666428

[yaswant]

@twsearle interesting concept 👍🏽 lets see if we have enough gas to archive the packages (I don't know if there is a limit). Couple of minor thoughts:

• instead of having the Dockerfile in the repo, you can have the hpccm configuration from jopa-container (and modify) and then generate the Dockerfile recipe via the workflow.
• perhaps have a sensible name for the image path on GHCR?

[twsearle]

@twsearle interesting concept 👍🏽 lets see if we have enough gas to archive the packages (I don't know if there is a limit). Couple of minor thoughts:

* instead of having the Dockerfile in the repo, you can have the hpccm configuration from jopa-container (and modify) and then generate the Dockerfile recipe via the workflow.

I tried this but I couldn't get it to work - the dockerfile generated had an incorrect path to download hdf5. You can see this if you diff the dockerfiles with this one. Happy to do it this way if you can get it working? I dont have an azure/ec2 box with root access to experiment... perhaps I should get one.

* perhaps have a sensible name for the image path on GHCR?

XD I thought orca-jedi/ci was a sensible name? What would you prefer, any suggestions?

[twsearle]

Oh in terms of the package archiving, orca-jedi is open so as far as I know, its packages are free.

[twsearle]

@yaswant on the hdf5 issue, It might be worth me opening a ticket with HPCCM? I believe this is the offending line:
https://github.com/NVIDIA/hpc-container-maker/blob/61175ab627682b82f054bb857afad12826af95c8/hpccm/building_blocks/hdf5.py#L135

and should read:

https://support.hdfgroup.org/ftp/HDF5/releases

I will ask in the hpccm repo and see what they say.

[twsearle]

NVIDIA/hpc-container-maker#488 opened an issue and PR with the container maker here.

[yaswant]

@yaswant on the hdf5 issue, It might be worth me opening a ticket with HPCCM? I believe this is the offending line: https://github.com/NVIDIA/hpc-container-maker/blob/61175ab627682b82f054bb857afad12826af95c8/hpccm/building_blocks/hdf5.py#L135

and should read:

https://support.hdfgroup.org/ftp/HDF5/releases

I will ask in the hpccm repo and see what they say.

We are aware of this, see https://github.com/MetOffice/jopa-container/commit/c61f023c0913fdd8d1eb36f44b5e078d8b8969b8 where we are now pointing to hdf5 GitHub to build the library instead of using default hpccm recipe. Glad that you have opened an issue with hpccm.

[twsearle]

We are aware of this, see MetOffice/jopa-container@c61f023 where we are now pointing to hdf5 GitHub to build the library instead of using default hpccm recipe. Glad that you have opened an issue with hpccm.

Ahh great thanks sorry I didn't see that change! I have put up the recipe as part of this PR. I will now make the adaptation to use automake and hpccm instead of just docker to build the container image.

[twsearle]

@yaswant is this any better?

[twsearle]

The plan would be to only build a package about once a tag, and they are very easy to housekeep.

[yaswant]

assuming that once this PR goes in and successfully push the Docker image, you will have another PR to use the image from GHCR instead of JCSDA image.

[twsearle]

assuming that once this PR goes in and successfully push the Docker image, you will have another PR to use the image from GHCR instead of JCSDA image.

Yep that was my thinking! I was thinking about this overnight, and perhaps it would have been better to make this change inside JOPA containers? I will put it here for now but let me know and we can just migrate it over in a new PR if that is best.