SansanandClaude Sonnet 5
d1d5ac8f98
CI / web (push) Successful in 22s
CI / go (push) Successful in 50s
CI / sqlc (push) Successful in 6s
CI / docker (push) Successful in 37s
Release / build-go (amd64, windows) (push) Successful in 23s
Release / build-go (amd64, linux) (push) Successful in 27s
Release / build-go (arm64, darwin) (push) Successful in 39s
Release / build-go (amd64, darwin) (push) Successful in 44s
Release / build-go (arm64, linux) (push) Successful in 35s
Release / build-web (push) Successful in 20s
Release / build-gui (amd64, windows, gcc-mingw-w64-x86-64) (push) Successful in 44s
Release / build-gui (amd64, linux, libgl1-mesa-dev xorg-dev libwayland-dev libxkbcommon-dev) (push) Successful in 56s
Release / build-docker (push) Successful in 52s
Release / release (push) Successful in 33s
build-go and build-gui now build straight to their final release filename (e.g. dist/Completed-api_linux_amd64, dist/Completed-gui_windows_amd64.exe) and upload-artifact uploads that directly - no separate Archive step, no zip/tar.gz wrapping a single or paired executable. build-web stays archived: it's not an executable, it's the built Angular site (a directory of HTML/JS/CSS/asset files), so bundling it into one tar.gz is still the right call there. Trade-off worth knowing: a raw upload doesn't preserve the Unix executable bit the way tar.gz did, so linux/darwin downloads need `chmod +x` before running; .exe downloads are unaffected. Documented in release.yml's comments. The release job's download/upload loop needed no changes - it already walks whatever's under artifacts/ with `find -type f`, regardless of how many raw files land in a given artifact's subdirectory. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>