4 Commits
Author SHA1 Message Date
SansanandClaude Sonnet 5 d1d5ac8f98 Upload raw executables in release.yml instead of zip/tar.gz
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>
2026-10-03 20:15:22 +02:00
SansanandClaude Sonnet 5 f1337e824e Downgrade release.yml's artifact actions to v3
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>
2026-10-03 20:01:11 +02:00
Sansan 51d6e24122 Trigger CI to check runner capacity/concurrency
Release / build-go (amd64, linux) (push) Failing after 36s
Release / build-go (amd64, darwin) (push) Failing after 36s
Release / build-go (arm64, darwin) (push) Failing after 37s
Release / build-go (amd64, windows) (push) Failing after 38s
Release / build-web (push) Failing after 20s
Release / build-go (arm64, linux) (push) Failing after 22s
Release / build-gui (amd64, linux, libgl1-mesa-dev xorg-dev libwayland-dev libxkbcommon-dev) (push) Failing after 31s
CI / sqlc (push) Successful in 10s
CI / go (push) Successful in 33s
CI / web (push) Successful in 18s
CI / docker (push) Successful in 50s
Release / build-docker (push) Successful in 1m41s
Release / build-gui (amd64, windows, gcc-mingw-w64-x86-64) (push) Failing after 4m36s
Release / release (push) Skipped
2026-10-03 19:19:40 +02:00
SansanandClaude Sonnet 5 066f316dc6 Install Wayland dev headers for the Fyne/glfw build in CI
CI / go (push) Successful in 2m29s
CI / sqlc (push) Successful in 5s
CI / web (push) Successful in 41s
CI / docker (push) Successful in 1m55s
Found by actually running ci.yml on the real Gitea instance: the go job
failed at go vet with "wayland-client-core.h: No such file or directory"
building go-gl/glfw (a Fyne dependency), which compiles in both its X11
and Wayland backends by default. libgl1-mesa-dev + xorg-dev alone aren't
enough; added libwayland-dev and libxkbcommon-dev to both ci.yml and
release.yml's linux packages list.

I'd only verified cmd/gui's build on macOS and via the Windows mingw-w64
cross-compile - never on an actual Linux machine, so this gap wasn't
visible until the real CI run hit it. sqlc, web and docker all passed on
that same run (confirmed from the job logs, not just the status column).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-10-03 15:44:58 +02:00
2 changed files with 34 additions and 37 deletions

No files matched your search

+7 -3
View File
@@ -15,12 +15,16 @@ jobs:
go-version-file: go.mod go-version-file: go.mod
# cmd/gui (Fyne) uses cgo and links against the system's OpenGL/X11 # cmd/gui (Fyne) uses cgo and links against the system's OpenGL/X11
# libraries, so building or testing ./... needs these present even # *and* Wayland libraries (go-gl/glfw compiles in both backends), so
# though the GUI itself never opens a window in CI. # building or testing ./... needs all of these present even though
# the GUI itself never opens a window in CI. Found by a real failure
# here, not guessed: go vet failed with "wayland-client-core.h: No
# such file or directory" when only libgl1-mesa-dev/xorg-dev were
# installed.
- name: Install system dependencies for the Fyne GUI build - name: Install system dependencies for the Fyne GUI build
run: | run: |
sudo apt-get update sudo apt-get update
sudo apt-get install -y libgl1-mesa-dev xorg-dev sudo apt-get install -y libgl1-mesa-dev xorg-dev libwayland-dev libxkbcommon-dev
- name: gofmt - name: gofmt
run: | run: |
+27 -34
View File
@@ -41,6 +41,12 @@ jobs:
with: with:
go-version-file: go.mod go-version-file: go.mod
# Built with their final release filenames directly (rather than a
# generic name plus a separate archive step), so what comes out of
# dist/ is exactly what gets uploaded: raw executables, no zip/tar.gz.
# One real trade-off: a raw upload doesn't preserve the Unix
# executable bit the way a tar.gz would, so linux/darwin downloads
# need a manual `chmod +x` before running; .exe is unaffected.
- name: Build api and tui - name: Build api and tui
env: env:
GOOS: ${{ matrix.goos }} GOOS: ${{ matrix.goos }}
@@ -50,23 +56,14 @@ jobs:
mkdir -p dist mkdir -p dist
ext="" ext=""
if [ "${{ matrix.goos }}" = "windows" ]; then ext=".exe"; fi if [ "${{ matrix.goos }}" = "windows" ]; then ext=".exe"; fi
go build -o "dist/completed-api${ext}" ./cmd/api suffix="${{ matrix.goos }}_${{ matrix.goarch }}${ext}"
go build -o "dist/completed-tui${ext}" ./cmd/tui go build -o "dist/${PROJECT_NAME}-api_${suffix}" ./cmd/api
go build -o "dist/${PROJECT_NAME}-tui_${suffix}" ./cmd/tui
- name: Archive - uses: actions/upload-artifact@v3
run: |
cd dist
base="${PROJECT_NAME}_${{ matrix.goos }}_${{ matrix.goarch }}"
if [ "${{ matrix.goos }}" = "windows" ]; then
zip "../${base}.zip" completed-api.exe completed-tui.exe
else
tar czf "../${base}.tar.gz" completed-api completed-tui
fi
- uses: actions/upload-artifact@v4
with: with:
name: ${{ env.PROJECT_NAME }}_${{ matrix.goos }}_${{ matrix.goarch }} name: ${{ env.PROJECT_NAME }}-go_${{ matrix.goos }}_${{ matrix.goarch }}
path: ${{ env.PROJECT_NAME }}_${{ matrix.goos }}_${{ matrix.goarch }}.* path: dist/*
retention-days: 7 retention-days: 7
# cmd/gui (Fyne) uses cgo, so unlike build-go above it can't just cross- # cmd/gui (Fyne) uses cgo, so unlike build-go above it can't just cross-
@@ -84,7 +81,7 @@ jobs:
include: include:
- goos: linux - goos: linux
goarch: amd64 goarch: amd64
packages: libgl1-mesa-dev xorg-dev packages: libgl1-mesa-dev xorg-dev libwayland-dev libxkbcommon-dev
- goos: windows - goos: windows
goarch: amd64 goarch: amd64
packages: gcc-mingw-w64-x86-64 packages: gcc-mingw-w64-x86-64
@@ -100,6 +97,8 @@ jobs:
sudo apt-get update sudo apt-get update
sudo apt-get install -y ${{ matrix.packages }} sudo apt-get install -y ${{ matrix.packages }}
# Same reasoning as build-go above: upload the raw executable, built
# with its final release name directly, no archive step.
- name: Build gui - name: Build gui
env: env:
GOOS: ${{ matrix.goos }} GOOS: ${{ matrix.goos }}
@@ -107,26 +106,17 @@ jobs:
CGO_ENABLED: "1" CGO_ENABLED: "1"
run: | run: |
mkdir -p dist mkdir -p dist
name="dist/${PROJECT_NAME}-gui_${{ matrix.goos }}_${{ matrix.goarch }}"
if [ "${{ matrix.goos }}" = "windows" ]; then if [ "${{ matrix.goos }}" = "windows" ]; then
CC=x86_64-w64-mingw32-gcc go build -ldflags "-H=windowsgui" -o dist/completed-gui.exe ./cmd/gui CC=x86_64-w64-mingw32-gcc go build -ldflags "-H=windowsgui" -o "${name}.exe" ./cmd/gui
else else
go build -o dist/completed-gui ./cmd/gui go build -o "${name}" ./cmd/gui
fi fi
- name: Archive - uses: actions/upload-artifact@v3
run: |
cd dist
base="../${PROJECT_NAME}-gui_${{ matrix.goos }}_${{ matrix.goarch }}"
if [ "${{ matrix.goos }}" = "windows" ]; then
zip "${base}.zip" completed-gui.exe
else
tar czf "${base}.tar.gz" completed-gui
fi
- uses: actions/upload-artifact@v4
with: with:
name: ${{ env.PROJECT_NAME }}-gui_${{ matrix.goos }}_${{ matrix.goarch }} name: ${{ env.PROJECT_NAME }}-gui_${{ matrix.goos }}_${{ matrix.goarch }}
path: ${{ env.PROJECT_NAME }}-gui_${{ matrix.goos }}_${{ matrix.goarch }}.* path: dist/*
retention-days: 7 retention-days: 7
build-web: build-web:
@@ -149,7 +139,7 @@ jobs:
- name: Archive - name: Archive
run: tar czf ${PROJECT_NAME}-web_dist.tar.gz -C web/dist/web/browser . run: tar czf ${PROJECT_NAME}-web_dist.tar.gz -C web/dist/web/browser .
- uses: actions/upload-artifact@v4 - uses: actions/upload-artifact@v3
with: with:
name: ${{ env.PROJECT_NAME }}-web_dist name: ${{ env.PROJECT_NAME }}-web_dist
path: ${{ env.PROJECT_NAME }}-web_dist.tar.gz path: ${{ env.PROJECT_NAME }}-web_dist.tar.gz
@@ -191,16 +181,19 @@ jobs:
needs: [build-go, build-gui, build-web] needs: [build-go, build-gui, build-web]
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- uses: actions/download-artifact@v4 - uses: actions/download-artifact@v3
with: with:
path: artifacts path: artifacts
merge-multiple: true # v3 has no merge-multiple: downloading all artifacts (no `name`
# given) lands each one in its own artifacts/<artifact-name>/
# subdirectory, not flattened - hence `find`, not a fixed-depth
# glob, in the step below.
- name: Upload to the Gitea generic package registry - name: Upload to the Gitea generic package registry
env: env:
VERSION: ${{ gitea.ref_name }} VERSION: ${{ gitea.ref_name }}
run: | run: |
for f in artifacts/*; do find artifacts -type f | while read -r f; do
name="$(basename "$f")" name="$(basename "$f")"
echo "Uploading $name" echo "Uploading $name"
curl --fail --user "${{ github.repository_owner }}:${{ secrets.TOKEN }}" \ curl --fail --user "${{ github.repository_owner }}:${{ secrets.TOKEN }}" \