SansanandClaude Sonnet 5
786fdbb0d5
cmd/api/main.go: registerWebUI serves a built web/ as a single-page app - Echo's static middleware in HTML5 mode, with a Skipper that exempts /api/*, /hello, /docs, /schemas/* and openapi.json/.yaml so it can never shadow a real API route. It reads WEB_DIST_DIR (default /frontend, where the Dockerfile puts it) and no-ops if that directory doesn't exist, so `go run ./cmd/api` and CI stay Node-free and API-only; only the Docker image actually turns the web UI on. Dockerfile: new node:22-alpine stage builds web/, copied into the final image at /frontend alongside the existing Go-built binary. Added .dockerignore (web/node_modules, web/dist, web/.angular, .git) now that a second language's tooling is in the build context. Looked at how your other Gitea projects (MusicServer et al.) structure this, since I can't exercise Gitea Actions itself from here: MusicServer's own Dockerfile already does "copy a prebuilt frontend into the Go image, serve it from Go" (there, from a separately-published frontend image) - registerWebUI does the same thing in spirit, just within one image rather than two, since this UI isn't meant to be published separately. release.yml: - build-gui now also cross-compiles the Fyne GUI for windows/amd64 via mingw-w64, alongside the existing linux/amd64. Verified for real, not just written: installed mingw-w64 locally and cross-built cmd/gui, first plain (got a working PE32+ console exe), then with -ldflags "-H=windowsgui" (got the GUI-subsystem exe actually wanted, no console window). macOS isn't attempted - cgo has no equivalent cross-toolchain for Darwin and there's no registered macOS runner here. - new build-docker job pushes the API image (now carrying the web build) to gitea.sanplex.xyz/sansan/completed, tagged with the version and latest. - replaced the hand-rolled curl+jq Gitea-release creation with akkuman/gitea-release-action, and artifact upload with the Gitea generic package registry - both are what your other projects (HanjaKanaMun, MusicPlayer) actually use, found by reading their workflows rather than guessing. Same for the registry host, owner, and secrets.TOKEN name (previously secrets.GITHUB_TOKEN, which nothing else here uses). ci.yml: new docker job builds the same image on every push to main/develop (push: false) as a health check, matching MusicServer's build-vs-release split. Verified for real wherever I could: a full `docker build` of the new Dockerfile, then running that image against a real Postgres container and hitting it with curl - / serves the actual built Angular index.html, /games (a client-side route) correctly falls back to it, /api/games and /hello are untouched (still return real API responses, not shadowed by the static handler), and register+list-games works end to end through the container. Also ran it the documented way, `docker compose up --build`, with the same results. Separately confirmed the Windows Fyne cross-build produces a real, correctly-subsystemed .exe. What I could not run from here is Gitea Actions itself - the workflow YAML is written to match your other projects' established, working conventions, but its first real execution on your Gitea instance is still the first real test of it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
99 lines
2.2 KiB
YAML
99 lines
2.2 KiB
YAML
name: CI
|
|
|
|
on:
|
|
push:
|
|
branches: [main, develop]
|
|
|
|
jobs:
|
|
go:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: actions/setup-go@v5
|
|
with:
|
|
go-version-file: go.mod
|
|
|
|
# cmd/gui (Fyne) uses cgo and links against the system's OpenGL/X11
|
|
# libraries, so building or testing ./... needs these present even
|
|
# though the GUI itself never opens a window in CI.
|
|
- name: Install system dependencies for the Fyne GUI build
|
|
run: |
|
|
sudo apt-get update
|
|
sudo apt-get install -y libgl1-mesa-dev xorg-dev
|
|
|
|
- name: gofmt
|
|
run: |
|
|
fmt_out="$(gofmt -l .)"
|
|
if [ -n "$fmt_out" ]; then
|
|
echo "The following files are not gofmt'd:"
|
|
echo "$fmt_out"
|
|
exit 1
|
|
fi
|
|
|
|
- name: go vet
|
|
run: go vet ./...
|
|
|
|
- name: go build
|
|
run: go build ./...
|
|
|
|
- name: go test
|
|
run: go test ./...
|
|
|
|
- name: go mod tidy (no diff expected)
|
|
run: |
|
|
go mod tidy
|
|
git diff --exit-code -- go.mod go.sum
|
|
|
|
sqlc:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: sqlc-dev/setup-sqlc@v4
|
|
with:
|
|
sqlc-version: "1.31.1"
|
|
|
|
- name: sqlc diff (generated code must match the schema/queries)
|
|
run: sqlc diff
|
|
|
|
web:
|
|
runs-on: ubuntu-latest
|
|
defaults:
|
|
run:
|
|
working-directory: web
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: actions/setup-node@v4
|
|
with:
|
|
node-version: "22"
|
|
cache: npm
|
|
cache-dependency-path: web/package-lock.json
|
|
|
|
- name: Install dependencies
|
|
run: npm ci
|
|
|
|
- name: Build
|
|
run: npm run build
|
|
|
|
- name: Test
|
|
run: npm test
|
|
|
|
# Builds the image on every push as a health check (catches a broken
|
|
# Dockerfile immediately); doesn't push anywhere. release.yml does the
|
|
# same build and pushes it.
|
|
docker:
|
|
runs-on: ubuntu-latest
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: docker/setup-buildx-action@v3
|
|
|
|
- name: Build
|
|
uses: docker/build-push-action@v5
|
|
with:
|
|
context: .
|
|
file: ./Dockerfile
|
|
push: false
|