-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor (ci): Update .github/workflows/build.yml code #5
Refactor (ci): Update .github/workflows/build.yml code #5
Conversation
lgtm |
@joeltimothyoh looking at this now, the templating using matrix and env vars makes the build job look much more complex than necessary. |
At least it would be maintainable but potential forkers of the repository, unlike having a dependency on code in and experience with PowerShell. @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. |
Matrices again are for the populating build environments with the necessary variable values for building however number of variants at scale. @leojonathanoh |
@joeltimothyoh matrices is simply a templator. to me, the The issue with using matrices, is that one puts the |
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 |
@joeltimothyoh for a simple repos with so few variants, it's better to make self-contained |
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 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". |
Opened #7 |
No description provided.