Refactor: Revise to push images on tag pushes

[joeltimothyoh]

Addresses #7

[joeltimothyoh]

Looks good enough to me @leojonathanoh

[leojonathanoh]

have you taken a look at #7 (comment)? It supports calver and semver tags on master / pr workflow, with auto releases and changelog

[joeltimothyoh]

I don't like the complexity. There are no such changelogs for game images as well than what's understandable via docker history. @leojonathanoh

[leojonathanoh]

when re-building images to a later base OS for instance, it will be nice to know the changes in the changelog. It will always be appreciated by consumers. And if any new variant(s) are added in future, that should also be in the changelog.

As for docker-sourceservers, that repo does not follow the conventional build on master workflow, so it's an exception. Whereas repos like this repo (which should actually be callled docker-steamcmd) and all other docker-* repos use the same workflow which is to build variants. To have repo-specific config makes it difficult to manage with more and more repos. As an example, look at the amount of maintenance it takes for a simple third party cloudflared docker image https://github.com/crazy-max/docker-cloudflared, which uses templating for a multi arch build https://github.com/crazy-max/docker-cloudflared/blob/2021.9.2-r0/docker-bake.hcl. And that repo has no variants and its .github/workflows/build.yml is already proprietary https://github.com/crazy-max/docker-cloudflared/blob/2021.9.2-r0/.github/workflows/build.yml. And even though it uses dependabot for dependency bump builds, it does manual releases https://github.com/crazy-max/docker-cloudflared/releases. Seems like a lot of work. And imagine if more images like that have to be built.

[leojonathanoh]

About docker history, while it may be viewable in Docker Hub or the command line, one should not assume the consumer would compare diffs between the old docker history and the newer docker history. So relying on docker history is not a changelog.

[joeltimothyoh]

About docker history, while it may be viewable in Docker Hub or the command line, one should not assume the consumer would compare diffs between the old docker history and the newer docker history. So relying on docker history is not a changelog.

True. Still, chances are that changes occurring to the images built by this repo are going to minimal. Most of the changes would be but dependencies for supporting building of third party game images. @leojonathanoh

[joeltimothyoh]

I'm not going to pretend that changes like these are doing much at all for the repo. I'm just going to keep things simple and rapid.

[joeltimothyoh]

Merging

[leojonathanoh]

the repo-specificity (repo-specific hardcoding) of the ci config may seem simple, but it is a double edged sword that will bite later on when one has too many repos with their own ci configs.