Refactor (ci): Update .github/workflows/build.yml code

[joeltimothyoh]

No description provided.

[joeltimothyoh]

lgtm

[leojonathanoh]

@joeltimothyoh looking at this now, the templating using matrix and env vars makes the build job look much more complex than necessary.

[joeltimothyoh]

At least it would be maintainable but potential forkers of the repository, unlike having a dependency on code in and experience with PowerShell. @leojonathanoh

[leojonathanoh]

@joeltimothyoh i don't mean to use an external templator. if templating is not necessary at all, as in this repo, then simply hardcoding the values will be sufficient in the build job.

[joeltimothyoh]

Matrices again are for the populating build environments with the necessary variable values for building however number of variants at scale. @leojonathanoh

[leojonathanoh]

@joeltimothyoh matrices is simply a templator.

to me, the Dockerfile should be completely self-contained (no ARGs, so that any consumer simply performs docker build -f Dockerfile to get the desired image) The other ci job options not pertaining to docker build command, are ci variables, and for ci logic it's beter to use a script (e.g. ./build/build.sh that can also be used outside the ci runner.

The issue with using matrices, is that one puts the Dockerfile values inside a templator (ci config file), where the Dockerfile is now no longer self-contained, and the ci config file cannot be used in a development environment. So this pattern is not good for consumers.

[joeltimothyoh]

I say it depends on use case. Pertaining to this project and it being OSS on GitHub, it suffices to use matrices with GHA.

This isn’t to say no improvements need to be made. I agree variables should be explicitly declared and abstractions done away with where possible. @leojonathanoh

[leojonathanoh]

@joeltimothyoh for a simple repos with so few variants, it's better to make self-contained Dockerfile, and there is no need for matrices in github workflows to keep things simple.

[leojonathanoh]

this repo also doesn't have release job and changelog. those are very important too. if a release is a calver-based release, then a date-based tag should be dynamically determined, and used for the build jobs to determine the docker image tag.

Hence a "simple" repo is usually one only has code and a manual ci release process, but with many other essential ci elements being missing e.g. automated releases, changelog, etc. If it's open source, the repo shouldn't actually be "simple".

[joeltimothyoh]

Opened #7