Build hyrax-builder images in CI (manual trigger)

[hannahilea]

Right now the docker images used across the hyrax ecosystem as CI images (and soon the base image for the bes image) are built and pushed manually.

Instead, build them in CI via a manual trigger.

To decide:

• What is naming strategy? Always latest?
• What is test strategy? Is there any test that needs to happen before these are pushed to dockerhub?
• Does any downstream process get triggered by a new image, e.g., rebuild the bes?

[hannahilea]

@ndp-opendap let's discuss/decide on the above open questions. Note that this is for a manual trigger still; automation won't happen until #100 (but strategy can be discussed there too).

[ndp-opendap]

I think the naming strategy should be to follow the docker hub model:

• latest - The most recent viable/blessed "release"
• snapshot - The most recent successful build
• version-build# - Everything should get a version-build# tag (ex: 1.0.0-645) These may also get tagged as snapshot or latest

The additional semantics of snapshot and latest might not be needed in the long run, but in the short term will allow us to build the things and not put the new builds into use unless a person makes it happen (like making a release ;))

Does that make sense?

[hannahilea]

I think that makes sense: as far as CI is concerned here, we should always push whatever we've built to dockerhub, with the tag "snapshot" and also a version number.
Questions:

• What should the process of making a release (i.e., adding a "latest" tag) look like? Do you imagine that it is done manually, and if so, where would it be documented?
• Where does this version number come from?

[ndp-opendap]

I think that makes sense: as far as CI is concerned here, we should always push whatever we've built to dockerhub, with the tag "snapshot" and also a version number. Questions:

• What should the process of making a release (i.e., adding a "latest" tag) look like? Do you imagine that it is done manually, and if so, where would it be documented?

I think we need some kind of actual test activity to verify that promoting a build to latest won't break the food chain. In the short term this testing needs to be manual, but hopefully we can automate it to the point that a person only needs to verify that the tests passed before the latest tag is applied.
If the tests are automated and seem reliable we could eventually automate the tagging of latest.

• Where does this version number come from?
  We make it up?? The build number can be something we get from Travis/GH but the version number... Hmmmmm

Maybe start with the linux version?

From rocky8:

cat /etc/rocky-release
Rocky Linux release 8.10 (Green Obsidian)

So 8.10-build# might be a starting point?