Extract binaries to releases#56
Conversation
…t-binaries-to-releases # Conflicts: # README.md # bin/embed-code-linux # bin/embed-code-macos # bin/embed-code-windows.exe
| shell: bash | ||
| run: | | ||
| mkdir -p dist | ||
| GOOS=windows GOARCH=amd64 go build -trimpath -o dist/embed-code-windows.exe main.go |
There was a problem hiding this comment.
Let's create bash script for it.
There was a problem hiding this comment.
I don't think we need separate Bash script files for such tiny scripts of only 4–7 lines.
| if gh release view "$RELEASE_TAG" >/dev/null 2>&1; then | ||
| git tag --force "$RELEASE_TAG" "$GITHUB_SHA" | ||
| git push origin "refs/tags/$RELEASE_TAG" --force | ||
| gh release edit "$RELEASE_TAG" \ |
There was a problem hiding this comment.
I'm not sure if updating a release is a good idea. Maybe we should create a new release for every merge? Or set up a separate deployment branch so we don't clutter the releases with patches. It's just strange that a release action doesn't actually create a new release, but instead just updates the existing one; it seems to me like this is hidden behavior—and it's certainly not documented.
There was a problem hiding this comment.
I don't think we need to force version updates, as we may have documentation or test changes that do not affect the app version. However, I agree that updating an existing release is not a good decision, so let's create a new release only when the version has been updated.
2 participants
This PR moves binaries storing to the Releases instead of version control.
From now on, the version tracker has been moved to the
VERSIONfile instead ofmain.go.If the version is not changed, merging the PR would update the binaries for the previous release.
Resolves this issue.