SansanandClaude Sonnet 5
f1337e824e
CI / go (push) Successful in 46s
Release / build-go (amd64, linux) (push) Successful in 47s
CI / docker (push) Successful in 51s
CI / sqlc (push) Successful in 9s
CI / web (push) Successful in 25s
Release / build-go (amd64, darwin) (push) Successful in 53s
Release / build-go (amd64, windows) (push) Successful in 52s
Release / build-go (arm64, darwin) (push) Successful in 31s
Release / build-go (arm64, linux) (push) Successful in 30s
Release / build-web (push) Successful in 17s
Release / build-gui (amd64, linux, libgl1-mesa-dev xorg-dev libwayland-dev libxkbcommon-dev) (push) Successful in 49s
Release / build-docker (push) Successful in 52s
Release / build-gui (amd64, windows, gcc-mingw-w64-x86-64) (push) Successful in 4m16s
Release / release (push) Successful in 18s
Found by actually running release.yml against a real v0.0.1 tag: every build-* job failed at actions/upload-artifact@v4 with "GHESNotSupportedError: @actions/artifact v2.0.0+, upload-artifact@v4+ and download-artifact@v4+ are not currently supported on GHES." - exactly the risk flagged (but not yet hit) when this workflow was first written. This Gitea Actions instance doesn't support the v4 artifact protocol; v3 does. v3 has no merge-multiple option: downloading all artifacts with no `name` given lands each one in its own artifacts/<artifact-name>/ subdirectory instead of flattened into artifacts/. Changed the generic-package-registry upload loop from a flat `artifacts/*` glob to `find artifacts -type f` so it finds files regardless of that nesting. Not yet confirmed: whether build-docker (needs secrets.TOKEN, still unset) and the rest of the release job succeed once the artifact step itself works - that's the next real run to check. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>