search

bloznelis / typioca

Cozy typing speed tester in terminal
MIT License
748 stars 20 forks source link

Build and release Github workflow #53

Closed sitiom closed 2 years ago

sitiom commented 2 years ago

Closes #52 Closes #51 Fixes https://github.com/bloznelis/typioca/pull/47#pullrequestreview-1021143376.

It works as intended on my fork.

Misc changes:

sitiom commented 2 years ago

@bloznelis You limited the workflow only on tag push (https://github.com/bloznelis/typioca/commit/a46f82034c3029cbe97e7114ba067d3824625877)? The workflow was made so the CI only builds and creates artifacts in each commit and PR and only releases in each tag push.

bloznelis commented 2 years ago

@sitiom Yes. Why do we need built artifacts if we are not going to release them?

sitiom commented 2 years ago
  1. Ensure pushed code is valid and successfully builds, especially on PRs
  2. Try out binaries on a specific commit for testing (especially on PRs as well)
bloznelis commented 2 years ago

While I do understand the incentive and value of validating that code compiles and builds on PR, I think that should be a different CI step and not mashed together with release making.

But regarding the trying out binaries for specific commit – I don't think it is worth the hassle. Can't one just checkout and build the code?

sitiom commented 2 years ago

While I do understand the incentive and value of validating that code compiles and builds on PR, I think that should be a different CI step and not mashed together with release making.

Can be done, it's just a hassle to create a new job and download the artifacts back again. But in terms of separation, it would certainly look cleaner.

But regarding the trying out binaries for specific commit – I don't think it is worth the hassle. Can't one just checkout and build the code?

For the end-users, it might be a hassle to them to need to have go installed and build the binaries themselves when they just want to try it out (especially if compiling is slow and the project is big). Most projects provide artifacts so they could try it out without needing anything else. A common use-case would be to have a "nightly" build of some software pointing to the artifact of the latest commit (https://nightly.link/).