GHCR cleanup

[cameronrutherford]

We currently have three different spack GHCR caches configured:

1. https://github.com/awslabs/palace/pkgs/container/palace-develop - we use this regularly
2. https://github.com/awslabs/palace/pkgs/container/palace - unused
3. https://github.com/awslabs/palace/pkgs/container/palace-v0.23.1 - unused

The last 2 caches can be completely removed as they were configured in testing CI and in order to support multiple spack versions. This isn't something we need / do anymore.

From - https://github.com/awslabs/palace/blob/main/.github/workflows/spack.yml#L127

There isn't really a great / convenient way to deal with cleanup of these caches over time. In other registries like ECR, one can configure auto-deletion after a certain amount of time, but that isn't currently possible in GHCR.

Maybe this would be the best we can do? https://github.com/marketplace/actions/ghcr-io-cleanup-action

From offline discussion with @Sbozzolo, I think a monthly wipe of our cache would be the most reasonable approach.

Why should we clean these up?

1. In theory, we will eventually run out of space in GHCR based on some upper limit in awslabs. I don't think that is the case yet, but eventually it would be.
2. It seems like this is slowing down some of the spack pipelines somewhat. See the following two pipelines for comparison:

• older pipeline w/ only 877 lines of output for this step.
• more recent pipeline w/ 1977 lines of output for this step.

So, while a once monthly cleanup will slow down the first pipelines we run each month, I think that this would be reasonable.

Alternatively, we could consider moving our GitHub pipelines to use ECR as the cache in the first place, which could then open up the possibility of using the same binaries to run on other AWS services we deploy. We would just have to be a little more careful about GPG keys, but would be reasonable. This would also enable some more advanced security scanning, which I am not sure we quite need / want.