ci(ci): Push built CI images to Quay

[ebaron]

This PR adds steps to our CI workflow that push the build image to Quay. This uses the redhat-actions/push-to-registry action. The step only runs on push, excluding forks. The image tags pushed to Quay are the image version defined in the POM (currently 2.0.0-SNAPSHOT), latest, and the commit SHA. The latter creates a new tag upon each commit. I'm not sure if we want this. It's nice for traceability, but will end up creating a lot of tags.

The push is done by a robot account in Quay, whose credentials will be stored in a Github secret [1]. To test, I temporarily substituted the Cryostat account for my own. The results can be seen below:

CI on PR, not pushed to Quay: https://github.com/ebaron/cryostat/runs/2975581732
CI on push, pushed to Quay: https://github.com/ebaron/cryostat/runs/2975629893

[1] https://docs.github.com/en/actions/reference/encrypted-secrets

[andrewazores]

Cool, looks good, although I do also think pushing/tagging an image for every upstream commit might be a bit much. Is there a way to do it for latest, the pom version, and any git tag that might also be associated with the commit? That way versions that have no git tag just bump latest and the pom version, but we can still put up things like betas and RCs using git tags.

Oh, I do have a question regarding the latest tag. If we apply this to both main and v1, we can remove the config for latest from v1 so that the latest tag is sort of "monotonically increasing", right?

[ebaron]

Cool, looks good, although I do also think pushing/tagging an image for every upstream commit might be a bit much. Is there a way to do it for latest, the pom version, and any git tag that might also be associated with the commit? That way versions that have no git tag just bump latest and the pom version, but we can still put up things like betas and RCs using git tags.

We could use the release event for Github releases, but it might be possible to to using tags [1]. Is this something we need though? For beta releases wouldn't we update the POM version as well?

Oh, I do have a question regarding the latest tag. If we apply this to both main and v1, we can remove the config for latest from v1 so that the latest tag is sort of "monotonically increasing", right?

I'm still not clear exactly how the workflows work in non-default branches, but we definitely want latest to only point to builds from main.

[1] https://docs.github.com/en/actions/reference/events-that-trigger-workflows#release

[andrewazores]

We could use the release event for Github releases, but it might be possible to to using tags [1]. Is this something we need though? For beta releases wouldn't we update the POM version as well?

I suppose we would, but this would mean we either have to update the pom version along with every PR after the first beta, or if we don't, then existing beta tags on quay.io would be overwritten by later builds with the same version.

I guess betas would come off an upstream version branch anyway, so updating the pom along with every backport PR would be okay.