[SYNPY-1341] Add CI step to containerize and upload synpy to the GHCR

[jaymedina]

problem

We recently added a GHCR image for the python client because there was no up-to-date image hosted anywhere. We should add a step to the CI workflow to publish new versions of the client as docker images automatically when a new version is released.

solution

Two new jobs (ghcr-build-and-push-on-merge, ghcr-build-and-push-on-develop) are created to build a multi-platform image of the repository and push it to the GitHub Container Registry.

ghcr-build-and-push-on-release

• The job should be triggered only for an official version release
  - [ ] The docker image should be multi-platform (AMD64, ARM64)
• The docker image tag should be named after the release version number

ghcr-build-and-push-on-develop

• The job should be triggered only for pushes to develop (i.e. PR merges)
  - [ ] The docker image should be multi-platform (AMD64, ARM64)
• The docker image tag should be named after the latest commit SHA on develop

testing & preview

ghcr-build-and-push-on-release

I manually fed a version v1.2.3test that will be fed into the Build and push Docker image step to test that this communication happens between Extract Release Version and Build and push Docker image.

Triggering the job results in a new release with the expected version name

I pulled the docker image and ran a container to confirm that the latest version v4.2.0 of the python client is running in the container:

ghcr-build-and-push-on-develop

develop image tag name reflects the latest commit it points to. Below is the example for commit 8303999 of this branch:

[rxu17]

LGTM! Just a question

[BryanFauble]

Excellent work!

[jaymedina]

This PR is now ready for a final review.

Latest changes:

• Each push to develop will trigger the job to generate a new image tagged with develop-[commit SHA] so that all images can be traced back to a point in the commit history. Examples:

• TLDR: The scope of this PR is adjusted to work with single platform images. The support of multi-platform images will be an enhancement ticket after this one is complete. The original intention was to support multi-platform images, however the way this has been working so far has led to untagged images being pushed alongside the official tagged image (see example below). These untagged images seem to be individual layers corresponding to one of the designated platforms (e.g. linux/arm64 created an untagged image, and linux/amd64 creates another). These extra untagged images being pushed to the registry add extra clutter, which I would like to minimize since the develop images will be filling up the registry on top of this, so I'll be opening a new ticket for tackling this behavior in a separate PR, and this feature will introduce automating the creation and push of SINGLE platform images onto the registry.

Feedback is welcome. Thanks!

[BryanFauble]

This all looks good to me! We can test this out and adjust based on feedback.

[jaymedina]

Great thanks @BryanFauble - Once all tests pass I'll squash and merge this.