Add Docker build workflow on release

[joewallwork]

Closes #156.

This PR sets up a separate workflow for building and pushing a Docker build for the release branch. It passes --build-arg BRANCH=release to the Firedrake Docker build. It's triggered on updates to the workflow and on a monthly basis.

[joewallwork]

Oh perhaps we should also customise the Dockerfile.firedrake-parmmg so that the release branches of Animate, Movement, and Goalie are checked out?

[joewallwork]

Oh actually, perhaps it makes more sense to have a release tag rather than a separate image? (And similarly elsewhere)

Suggested change

	docker-image-tag: 'ghcr.io/mesh-adaptation/firedrake-parmmg-release:latest'
	docker-image-tag: 'ghcr.io/mesh-adaptation/firedrake-parmmg:release'

[joewallwork]

Done in d0907b2.

[joewallwork]

@stephankramer do you have any idea what might be going wrong in the release Firedrake build?
https://github.com/mesh-adaptation/docs/actions/runs/21061040568/job/60567210729?pr=170
It says it can't build wheels for Firedrake.

[stephankramer]

So I think the problem is that when building the base container from firedrake's Dockerfile.vanilla, if we're building firedrake release (by passing that branch as a build argument), the Dockerfile.vanilla itself also needs to come from the release branch of firedrake (because the build sequence may have changed between release and main).

I renamed the firedrake-branch input to dockerfile-branch input, so that we can default it to the github ref associated with the triggering action (e.g. the PR branch, or main after the merge) for the Dockerfiles that are in this docs/ repo. The same input is also still passed as a build argument to specify which firedrake branch to build, but that's only picked up anyway if the actual base container is being build from firedrake's Dockerfile.vanilla, and safely ignored when building the subsequent ones from the Dockerfiles in docs/.

[joewallwork]

So I think the problem is that when building the base container from firedrake's Dockerfile.vanilla, if we're building firedrake release (by passing that branch as a build argument), the Dockerfile.vanilla itself also needs to come from the release branch of firedrake (because the build sequence may have changed between release and main).

I renamed the firedrake-branch input to dockerfile-branch input, so that we can default it to the github ref associated with the triggering action (e.g. the PR branch, or main after the merge) for the Dockerfiles that are in this docs/ repo. The same input is also still passed as a build argument to specify which firedrake branch to build, but that's only picked up anyway if the actual base container is being build from firedrake's Dockerfile.vanilla, and safely ignored when building the subsequent ones from the Dockerfiles in docs/.

Ah okay, that makes sense. Thanks for looking into this! I'll come back to my other unresolved comments above.

[joewallwork]

Oh perhaps we should also customise the Dockerfile.firedrake-parmmg so that the release branches of Animate, Movement, and Goalie are checked out?

Done in a9b6d6d.

[joewallwork]

@stephankramer please could you review this? I think it's ready now.

[stephankramer]

Oh sorry, quoting myself from above:

I renamed the firedrake-branch input to dockerfile-branch input, so that we can default it to the github ref associated with the triggering action (e.g. the PR branch, or main after the merge) for the Dockerfiles that are in this docs/ repo. The same input is also still passed as a build argument to specify which firedrake branch to build, but that's only picked up anyway if the actual base container is being build from firedrake's Dockerfile.vanilla, and safely ignored when building the subsequent ones from the Dockerfiles in docs/.

having another at the changes in the PR - I realize this is no longer true :-(
docker/Dockerfile.firedrake-parmmg now also uses the BRANCH build argument to decide which version of animate/movement and goalie to check out. So we can't use inputs.dockerfile-branch for that because that will be set to the branch of docs/ to decide which version of docker/Dockerfile.firedrake-parmmg to use.

So we probably need two separate inputs to the reusable build worflow:

1. dockerfile-branch to decide which branch of the specified dockerfile-repo to use to checkout the dockerfile
2. firedrake-branch to decide which branch to pass on as the BRANCH build argument when building the container from that dockerfile