Feat/tagged versions

[gknapp1]

Summary

This is basically a full rewrite of the containers repository to better enable container versioning, ease of updating container versions, and speed of building. Overall, modernizes the container build and release pipeline with Bake-based image definitions, dependency-aware CI, immutable release tags, and generated container inventory documentation.

In terms of user experience, this will require manual updates of versions, ideally from versioned spack installs (AdditiveFOAM is an exception to building from a spack image due to the availability of an OpenFOAM official container and the slowness of building the spack openfoam install). This moves container publishing from a weekly build to a publish-on-merge-to-main model.

To avoid confusion on compatibility, the tags are changed to a date-based format (YYYY-MM-DD) so that each version of the container is unique.

Related issues

• Closes Create version of container with fixed versioning #4
• Closes spack package manager doesn't work with uv pacakge manager #11 (no longer relevant)
• Closes Create container with fixed spack and base dependency versions #14

Details

• Replaces the single Docker build workflow with public Bake targets for Ubuntu, AdditiveFOAM, ExaCA, and Thesis.
• Adds shared Spack manifests and an Ubuntu base image so solver images reuse a common toolchain.
• Detects changed images and downstream dependencies, refreshing affected Spack lockfiles in CI.
• Publishes immutable UTC date release tags through a private staging flow, only publishing public packages for fully validated image digests
• Adds embedded inventory artifacts and generated documentation for published containers.
• Adds runtime smoke tests and unit coverage for target selection, release-tag selection, Dockerfile layout, and documentation generation.
• Documents local builds, smoke testing, release behavior, and CI validation expectations.
• Myna will now be able to call the associated containers in the Myna input files for running examples (via the Docker container options in Myna inputs), so GitHub CI will not have to run inside a monolithic container

Impact

This changes the build, publication, and inventory workflow for all repository images. It improves reproducibility, reduces duplicated solver build work, and makes installed software discoverable without running containers.

Risk level: Medium, because the CI release pipeline and image build structure are substantially revised, checking will be necessary on push to main. The workflow uses pinned external inputs, staged publication, validation before promotion, and generated inventory checks to reduce release risk.

Testing strategy

CI runs the following fast checks for every PR:

PYTHONDONTWRITEBYTECODE=1 python3 -m unittest discover -s tests -v
docker buildx bake --print
git diff --check

For affected images, CI also builds the Bake targets and runs scripts/container-smoke-tests.sh before publication. Registry-dependent staging, promotion, and catalog generation are validated on pushes to main.