Open
Conversation
Signed-off-by: Micah Halter <micah@balena.io>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Great work on this project! I love the use of GitHub actions for the build process and was interested in adding the ability to make more "official" releases of my configuration over time that would be more static/long lasting and easy to revert back to previous working versions.
Note: This GitHub action used to be maintained by GitHub (https://github.com/actions/upload-release-asset) but active development has moved to this new repository (https://github.com/softprops/action-gh-release). So while it's not maintained by the official GitHub developers anymore, this repository is very active and seems to be promoted by the official actions account so should be reliable and long living.
Basically it checks to see if the action is building on a "tag" (created with something like
git tag v1.0) and if it is, then it will create a release and upload the firmware as a release artifact. If it is just a normal push/PR to any branch then this step is skipped all together.Let me know if this would be a worthy/useful addition to the standard configuration template. I have just found it useful in my workflow and figured it would provide a good way for packaging official configuration versions for something like the Nice!60 board (https://github.com/Nice-Keyboards/nice60-zmk-config) in the future.