Add New Build Containers Workflow

[alecbcs]

This pull request adds a new workflow to build and deploy Spack Docker containers from GitHub Actions. In comparison with our current system where we use Dockerhub's CI to build our Docker containers, this workflow will allow us to now build for multiple architectures and deploy to multiple registries. (At the moment x86_64 and Arm64 because ppc64le is throwing an error within archspec.) This PR came out of a discussion with @tgamblin and @vsoch on how we might begin moving away from our reliance on DockerHub. As currently set up, the PR will build all of the current containers (minus Centos6 because those yum repositories are no longer available?) as both x86_64 and Arm64 variants. The workflow is currently setup to build and deploy containers nightly from develop as well as on tagged releases. The workflow will also build, but NOT deploy containers on a pull request for the purposes of testing this PR. At the moment it is setup to deploy the built containers to GitHub's Container Registry although, support for also uploading to Dockerhub/Quay can be included easily if we decide to keep releasing on Dockerhub/want to begin releasing on Quay. Let me know if you all have any suggestions for additional functionality!

Best,
Alec

[vsoch]

Woohoo! First time contributor, welcome @alecbcs ! 🥳

[alecbcs]

@tgamblin @vsoch @alalazo what do you all think about merging this in a test capacity where we're only pushing to GHCR to start? That way docker hub can continue to build the same containers it's been building and this won't disrupt anyone's workflows. But! It'd also allow us to start testing these containers with Autamus to make sure they're consistent with the current containers and the workflow is working as expected before we update this workflow to push to docker hub and ECR?

[vsoch]

I like the idea!

[tgamblin]

Let me talk to @opadron, @scottwittenburg, and @zackgalbreath today at the Kitware meeting. The only thing really keeping us on docker hub is that the CI uses those containers. If they can switch CI over we can move easily. I think @alecbcs's idea is also good and we can do that almost immediately -- I think it would be good if @scottwittenburg could take a look before this goes in though.

[tgamblin]

ok @scottwittenburg is going to look at this.

[scottwittenburg]

This is cool! I have no problem with it because it doesn't affect anything with gitlab CI pipelines 😆

So let me just explain briefly why that is. We have a few software stacks that get tested on every PR and merge to develop, the first of which was E4S. That stack is maintained by @eugeneswalker, and I want to build packages with the runner images he has created, mainly because they come with the compilers of interest to E4S pre-installed. And then since his containers live on DockerHub, I currently take the manual step (:shame:) of re-tagging them and pushing them to ghcr so our pipelines don't get rate-limited. In order to use the images built from the Dockerfiles in spack (the ones pushed so nicely without DockerHub by this PR), I think we'd need to get those to look more like what @eugeneswalker is making. That might be mostly about compilers, but there might be other things in the E4S runner images I depend on, but I'm forgetting right now.

For the rest of the stacks (other than E4S), pipelines leave it up to whoever contributes the stack to point at whatever image repository they want, though if it's DockerHub, it will problematic if the repo isn't "open source" as judged by DockerHub.

[alecbcs]

Cool! @scottwittenburg if you're interested and can get a Dockerfile together at some point we can totally extend this workflow to build a spack-ci container. All we'd have to do is add the Dockerfile to the other existing ones in the Spack Repo and update the parameter matrix in this workflow to include that Dockerfile and the architectures you'd want to build for. But that all can totally be done at a later date when you have time.

[scottwittenburg]

@alecbcs Those E4S dockerfiles for the E4S runners come from here. We should involve @eugeneswalker to talk about what kind of automation he has for building those now, and if it would be helpful if spack gha built them for him or not. There are a lot of images there, so maybe it's more than we should consider adding to this workflow down the road? Not sure.

Anyway, thanks!

[vsoch]

It those are in a separate repo, it would make sense to have the GitHub workflow to build them alongside it (so separate from this PR).

[scottwittenburg]

@vsoch Yes, I totally agree with that.