tinygo-org/tinygo
1
0
Fork 0
mirror of https://github.com/tinygo-org/tinygo.git synced 2026-08-31 17:59:03 +00:00
Code Issues Packages Projects Releases 6 Wiki Activity

ci: publish a draft release from the artifacts that CI already built

Browse Source 
The Linux, macOS and Windows workflows build every file that a release
needs when the release branch is pushed. The new Release workflow finds
those runs for the tagged commit, waits for them, and collects their nine
files into a draft release. It builds nothing, so what ships is what was
tested.

The release notes come from the CHANGELOG.md entry for that version.

Signed-off-by: Ron Evans <ron@hybridgroup.com>
This commit is contained in:
deadprogram
2026-08-29 09:55:07 +02:00
committed by Ron Evans
parent 421d98b248
commit 61c315cbfb
3 changed files with 225 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
BUILDING.md
+32
View File
@@ -123,3 +123,35 @@ the following command (for example in ~/lib):
TinyGo will get extracted to a `tinygo` directory. You can then call it with:
./tinygo/bin/tinygo
## Publish a release
The `Release` workflow (`.github/workflows/release.yml`) publishes releases. It
does not build anything. The Linux, macOS and Windows workflows already build
every file that a release needs when the `release` branch is pushed, so the
release workflow collects the artifacts of those runs for the tagged commit.
What ships is what was tested.
1. On the `dev` branch, set `const version` in `goenv/version.go` to the new
version (without a `v` prefix), and add the entry to `CHANGELOG.md`.
2. Merge `dev` into the `release` branch.
3. Tag that commit and push the tag:
git tag v0.42.0
git push origin v0.42.0
The tag must be `v` plus the version in `goenv/version.go`, because the
release file names come from that constant.
4. The workflow waits for the Linux, macOS and Windows runs of the tagged
commit, collects their nine files, and creates a **draft** release. The
release notes come from the `CHANGELOG.md` entry for that version.
5. Review the draft release and publish it.
6. On the `dev` branch, set `goenv/version.go` to the next `-dev` version.
To release again after a failure, delete the draft release and start the
workflow from the Actions tab with the tag as its input.
GitHub keeps a SHA-256 digest of every published file. The digest is not shown
on the release page, but it can be printed with:
gh release view v0.42.0 --json assets --jq '.assets[] | "\(.digest) \(.name)"'