ci: docker push (-> ghcr)

[tristan-f-r]

This PR makes it easy to push docker images. This also gives us a static list of what architectures we support, closing #272.

Since this is a little more inconvenient to do with the Docker Registry, we continue with the GHCR (closes #77), and create a new workflow that allows maintainers to deploy containers on certain versions.

To make this convenient, a metadata.json file is added to every single docker-wrapper (should we lint this?) which specifies what the actual desired docker name is.

---

The versioning comments have been addressed. Original comment:

Note: Until SPRAS is out of zerover, should we follow the versioning scheme v1.0.0-x for breaking changes to these containers? Or, should we just do v0.4.1-x (current version of SPRAS at the time of writing), where x is incremented for every breaking change?

I like the idea of using v1.0.0-x, as it indicates that SPRAS should be used once it's stable. I've currently pushed the containers as v1 (in current convention), but we can change it.

[tristan-f-r]

DOMINO and OI2 aren't building on arm64. Can't find the source for DOMINO #235, but an issue is open related to OI2: #315.

[tristan-f-r]

I've decided to allow images to specify architectures, and make some architecture support a burden of the algorithm Dockerfile wrapper instead.

[read-the-docs-community]

Documentation build overview

📚 spras | 🛠️ Build #30953207 | 📁 Comparing 902292a against latest (90ee7a3)

🔍 Preview build

Show files changed (2 files in total): 📝 2 modified | ➕ 0 added | ➖ 0 deleted

File	Status
install.html	📝 modified
contributing/index.html	📝 modified

[agitter]

I took an initial pass and like @jhiemstrawisc's opinions as well.

This change would mean we are no longer pushing new images to our DockerHub organization. Are there consequences to that? SPRAS doesn't much of an external userbase, so perhaps not yet. If it did, we may be abandoning users who couldn't get new images that newer versions of the SPRAS package required at some point in the future.

In terms of versioning, Justin and I originally discussed how the Docker images aren't tied to a specific SPRAS release. That's why we started an integer versioning convention. There is some implicit relationship where pathway reconstruction algorithm vX is only compatible with SPRAS >= vY. Ideally that would be explicit.

That versioning still makes sense to me because users need to know what version of a pathway algorithm image they are using and may need to change that version independently of the SPRAS package version. Even if we switch registries, I don't think we should reset versions at v1.

I would also like some way to document release notes for each Docker image as we iterate on them. That is currently done in the readmes. Should we keep it there?

Making this change would add another step to the contributing guide.

[tristan-f-r]

This change would mean we are no longer pushing new images to our DockerHub organization. Are there consequences to that?

As you've mentioned, this would only affect current users that have not changed their configured container registry to be ghcr.io yet continue to update SPRAS.

That versioning still makes sense to me because users need to know what version of a pathway algorithm image they are using and may need to change that version independently of the SPRAS package version.

I don't believe this case would happen, but I do see the rest of the motivation for decoupling the docker image versions from the SPRAS versions - also possibly because seeing a different SPRAS version appear in errors for docker containers can be misleading.

I would also like some way to document release notes for each Docker image as we iterate on them. That is currently done in the READMEs. Should we keep it there?

This is fine, we just need to be consistent about it. It might be a good idea to begin making all of the container READMEs consistent in the first place.

[tristan-f-r]

I left this PR decaying - @jhiemstrawisc I changed the versions, with the exception of AllPairs which had an undocumented v3. That version was probably just an artifact of a bad AllPairs push during #223, so it doesn't matter.

I've also updated build.py to allow for better support for --load.