Skip to content

feat: support golang (#41) #10

feat: support golang (#41)

feat: support golang (#41) #10

Workflow file for this run

name: Release
on:
push:
tags:
- 'v*'
env:
CARGO_TERM_COLOR: always
permissions:
contents: write
jobs:
build:
name: Build ${{ matrix.asset }}
runs-on: ${{ matrix.runner }}
strategy:
fail-fast: false
matrix:
include:
# Linux builds target musl and link statically, so one binary per arch
# runs on any distro regardless of glibc version.
- runner: ubuntu-22.04
target: x86_64-unknown-linux-musl
asset: sandd-linux-amd64
package: sandd
bin: sandd
- runner: ubuntu-22.04-arm
target: aarch64-unknown-linux-musl
asset: sandd-linux-arm64
package: sandd
bin: sandd
# No Intel-mac (x86_64-apple-darwin) leg: GitHub is retiring the
# macos-13 (Intel) runners, so that job queues indefinitely and — with
# `release` gated on `needs: build` — blocks the whole release from
# publishing. Apple Silicon (macos-14/arm64) covers modern Macs.
- runner: macos-14
target: aarch64-apple-darwin
asset: sandd-darwin-arm64
package: sandd
bin: sandd
# THE DAEMON ONLY. There is deliberately no sandd-controller asset and no
# controller image: the controller is not a deployed artifact any more. Its
# only consumer, Nebula, compiles it INTO its manager process through the C
# ABI (server/src/ffi.rs), because a daemon's connection is a live socket
# owned by whichever process accepted it — so reaching back into a workload
# from a separate controller process would mean relaying.
#
# `cargo build --bin sandd-controller` and `make docker-build-controller`
# still work for anyone who wants to run it standalone. They are just not
# release artifacts, and publishing them would imply a supported deployment
# shape that nothing uses.
steps:
- uses: actions/checkout@v4
- name: Install Rust toolchain
uses: actions-rust-lang/setup-rust-toolchain@v1
with:
toolchain: stable
target: ${{ matrix.target }}
- name: Install musl tools
if: endsWith(matrix.target, '-musl')
run: sudo apt-get update && sudo apt-get install -y musl-tools
- name: Build ${{ matrix.bin }}
run: |
cargo build --package ${{ matrix.package }} --bin ${{ matrix.bin }} \
--release --locked --target ${{ matrix.target }}
- name: Rename binary
run: mv target/${{ matrix.target }}/release/${{ matrix.bin }} ${{ matrix.asset }}
- name: Verify static linking
if: endsWith(matrix.target, '-musl')
run: |
# rustc emits a static-PIE for musl targets, which `file` reports as
# "static-pie linked" rather than "statically linked" -- accept either.
file ${{ matrix.asset }}
if ! file ${{ matrix.asset }} | grep -qE "static-pie linked|statically linked"; then
echo "::error::Expected a statically linked musl binary."
exit 1
fi
- name: Verify binary runs
run: ./${{ matrix.asset }} --help
- name: Upload artifact
uses: actions/upload-artifact@v4
with:
name: ${{ matrix.asset }}
path: ${{ matrix.asset }}
if-no-files-found: error
release:
name: Publish release
needs: build
runs-on: ubuntu-latest
steps:
- name: Download artifacts
uses: actions/download-artifact@v4
with:
path: artifacts
merge-multiple: true
- name: Generate checksums
run: |
cd artifacts
# The checksums file is excluded from its own input, so a re-run of this
# workflow cannot hash the file it is about to overwrite.
sha256sum $(ls sandd-* | grep -v '^sandd-checksums.txt$') > sandd-checksums.txt
cat sandd-checksums.txt
- name: Create or update release
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
# A release for this tag may already exist (e.g. cut by hand, or a
# re-run of this workflow). `gh release create` hard-fails in that
# case, so upload the assets to the existing release instead.
if gh release view "$GITHUB_REF_NAME" --repo "$GITHUB_REPOSITORY" >/dev/null 2>&1; then
echo "Release $GITHUB_REF_NAME already exists; uploading assets."
gh release upload "$GITHUB_REF_NAME" \
--repo "$GITHUB_REPOSITORY" \
--clobber \
artifacts/*
else
gh release create "$GITHUB_REF_NAME" \
--repo "$GITHUB_REPOSITORY" \
--title "$GITHUB_REF_NAME" \
--generate-notes \
artifacts/*
fi