Add tag-triggered release workflow
Some checks failed
CI / macos (push) Successful in 39s
Release / macos (push) Failing after 33s
CI / linux (push) Has been cancelled
Release / linux (push) Failing after 3m11s
Release / release (push) Has been skipped

Builds macos-arm64 and linux-x86_64 release binaries in parallel and
uploads them as build artifacts; a single release job gated on both
then downloads and publishes them to one Forgejo release. Splitting it
this way avoids a real race in actions/forgejo-release itself: its
script always does a blind create-then-upload for the tag with no
merge path, so two parallel callers against the same tag either
hard-fail or stomp each other's uploaded assets.
This commit is contained in:
randogoth 2026-10-07 20:03:18 +03:00
parent d85427156e
commit 73408bdf24

View file

@ -0,0 +1,97 @@
name: Release
on:
push:
tags: ["v*"]
jobs:
macos:
runs-on: macos-arm64
steps:
- uses: https://code.forgejo.org/actions/checkout@v4
with:
path: carrier
- uses: https://code.forgejo.org/actions/checkout@v4
with:
repository: randogoth/fumi
ref: main
path: fumi
- uses: https://code.forgejo.org/actions/cache@v4
with:
path: |
~/.cargo/registry
carrier/target
fumi/target
key: cargo-macos-${{ hashFiles('carrier/Cargo.lock') }}
restore-keys: cargo-macos-
- run: devbox run build
working-directory: carrier
env:
GITHUB_TOKEN: ""
- run: mv target/release/carrier target/release/carrier-macos-arm64
working-directory: carrier
# archive: false uploads the raw binary (not a zip) and names the
# artifact after the file, so this rename is what keeps the two
# platforms' artifacts from colliding under the same "carrier" name.
- uses: https://code.forgejo.org/actions/upload-artifact@v4
with:
name: carrier-macos-arm64
path: carrier/target/release/carrier-macos-arm64
archive: false
linux:
runs-on: linux-x86_64
steps:
- uses: https://code.forgejo.org/actions/checkout@v4
with:
path: carrier
- uses: https://code.forgejo.org/actions/checkout@v4
with:
repository: randogoth/fumi
ref: main
path: fumi
- uses: https://code.forgejo.org/actions/cache@v4
with:
path: |
~/.cargo/registry
carrier/target
fumi/target
key: cargo-linux-${{ hashFiles('carrier/Cargo.lock') }}
restore-keys: cargo-linux-
- run: devbox run build
working-directory: carrier
env:
GITHUB_TOKEN: ""
- run: mv target/release/carrier target/release/carrier-linux-x86_64
working-directory: carrier
- uses: https://code.forgejo.org/actions/upload-artifact@v4
with:
name: carrier-linux-x86_64
path: carrier/target/release/carrier-linux-x86_64
archive: false
# forgejo-release.sh (the engine behind actions/forgejo-release) always
# does a blind create-then-upload of the release for the tag, with no
# check for one already existing - running it from two parallel jobs
# against the same tag either hard-fails the second create (override:
# false) or races a delete-and-recreate that can wipe out the first job's
# just-uploaded assets (override: true). So platform jobs only ever
# produce artifacts; exactly one job, gated on both finishing, does the
# single release create + upload.
release:
needs: [macos, linux]
runs-on: linux-x86_64
steps:
- uses: https://code.forgejo.org/actions/download-artifact@v4
with:
path: dist/release
merge-multiple: true
- uses: https://code.forgejo.org/actions/forgejo-release@v2.13.4
with:
direction: upload
release-dir: dist/release
# Safe here specifically because this is the only job that ever
# calls forgejo-release for a given tag: re-running this same job
# for the same tag (e.g. a manual rerun) replaces its release
# cleanly instead of failing on "already exists".
override: true