Docker publish workflow: Create docker-publish.yml

[kalsi-avneet]

• Build using the Dockerfile and publish to ghcr.io (Github's container registry)

• Trigger on release

• Create the following tags based on the release git tag.

  For example, for a git tag v1.2.3, the following docker tags will be created:

  • 1.2.3 (version)
  • 1.2 (major.minor) <-- Removed as per review
  • 1 (major) <-- Removed as per review
  • latest

  Note: Depends on the git tag following semantic versioning.

[pbiering]

1.2 (major.minor) + 1 (major) makes no sense, only (latest) release + (latest) upstream makes sense, please adjust, thank you!

[kalsi-avneet]

1.2 (major.minor) + 1 (major) makes no sense, only (latest) release + (latest) upstream makes sense, please adjust, thank you!

Thank you for the review. I have removed the following as per your suggestion:

• 1.2 (major.minor)
• 1 (major)

[pbiering]

thank you

[pbiering]

@kalsi-avneet - would it make sense to create in addition "latest" on every push or pull-request using the commit hash instead of the release in the name? And somehow remove former "latest" ones in a cycled way, e.g. keep the last 10 images or only with creation time of the last 30 days?

[kalsi-avneet]

Hi @pbiering,

would it make sense to create in addition "latest" on every push or pull-request using the commit hash instead of the release in the name?

Let me confirm my understanding. The requirement is to create a docker image whenever:

• A commit is pushed to some branch (Let us assume master for this case), and
• A pull request is created

And the tag of the docker image should be the commit hash.

The above should be done in addition to creating images for every release.

Please confirm if my understanding same as yours.

---

I believe a few things need to be considered and discussed:

1. In the case of "on every push", should the image creation trigger be limited to git commit push to a particular branch (e.g. master)? if so, please share the branch/list of branches.
2. I am concerned that creating an image on every push might result in a lot of images especially if there is active development (lots of commits). Please share your opinion if it is ok to go ahead with this.
3. Since it is possible for a pull-request to contain multiple commits, I think it might be better to tag using the pull-request ID or something else instead of just commit hash. Please share your opinion.

And somehow remove former "latest" ones in a cycled way, e.g. keep the last 10 images or only with creation time of the last 30 days?

Yes, I think it would be possible. But the implementation would differ based on where the images are stored - github registry or dockerhub registry.
Allow me some time to do a little feasibility study and get back to you.

[pbiering]

instead of using push/pull-request as a trigger, can be a nightly image creation scheduled? Or e.g. trigger the "upstream" image generation manually from time to time?

[kalsi-avneet]

instead of using push/pull-request as a trigger, can be a nightly image creation scheduled? Or e.g. trigger the "upstream" image generation manually from time to time?

Yes, that can be done. I will create a PR for this.

Later, I will create another PR for cleanup

[kalsi-avneet]

@pbiering ,

Raised #1779 for your request:

instead of using push/pull-request as a trigger, can be a nightly image creation scheduled? Or e.g. trigger the "upstream" image generation manually from time to time?

Summary of PR:

• Trigger docker image creation automatically at 00:00 UTC daily.
• Ability to trigger image creation manually.