Replace committed binary with GitHub actions workflow #18
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Switches to specifying a dependency to a specific git tag [1] rather than the master branch, for a dependency which happens to be another repository of the protodot author. Note: the author of this specific commit is not currently familiar with go. When trying to update the "Gopkg.lock" file it became apparent the tool is used by Go's *deprecated* "dep" dependency management tool rather than the modern "go mod" tool which uses "go.mod" file (which is present in this repository). This commit still will be useful for systems which haven't been updated though. By pointing to a specific git tag, users building locally will no longer unknowingly pull in newer (in future, possibly API breaking) changes from that repository, as new commits are inevitably added to its master branch. The most recent release of protodot is v1.2.0 (2023-04-12), which based on timestamps must have originally been built with seamia/tools v1.0.12 (2021-08-08). However, the most recent binary upload (hosted within the repository) was commited on 2023-12-12, which indicates it was likely built with seamia/tools v1.1.8 (2023-11-30) [1] https://github.com/seamia/tools/tree/v1.1.8
Deletes the entire "binaries/" folder. Hosting release binaries built from a developer's machine stored within a git repository is hard to audit, compared to build scripts running in a continuous integration environment (next commit). Also binaries committed in a git repository (when not using Git Large File Storage) causes speed problems as more binaries are added, as git is optimized for text data not binary data.
Adds GitHub Actions workflow file to build a protodot binary for all the operating systems and architectures currently listed in the binaries folder. Plus Linux arm64, because that's a relatively popular platform too.
Special care taken to ensure Windows exe extension preserved.
shasheene
commented
Nov 2, 2024
| # The former is available on each GitHub Actions workflow run. The latter is associated with only a pushed tag. | ||
|
|
||
| - name: Upload release artifacts except Windows | ||
| uses: actions/upload-artifact@v4 |
There was a problem hiding this comment.
Whoops I lost the following line that's supposed to be here
if: matrix.go-os-target != 'windows'
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi @seamia,
I find this project very useful, thank for making it!
But hosting arbitrary binaries built on a developer's system within the git repository is not ideal.
The solve this, I have developed a GitHub Actions workflow file so that when a git tag release is pushed to GitHub, the binaries are automatically built for a variety of platforms and uploaded to GitHub's release page as an asset.
You can see an example of this here: https://github.com/shasheene/protodot/releases/tag/test-new-tag
Separately, there is the concept of GitHub Actions artifact, a shorter lived entity that is uploaded upon every push but only within the GitHub Actions run with some finite retention period. You can see an example of the artifact at the very bottom of this page: https://github.com/shasheene/protodot/actions/runs/11640198456
Once this PR is merged, pushing a new tag should generate a new official release automatically!
But you may want to play around with it further, typically in a separate repository, because GitHub Actions can be very finicky to develop with!