Adopts the FabledRulebook ci-runners.md policy: workflows select
toolchains via container.image, not via runs-on labels. `runs-on`
stays as the scheduling handle only.
Workflows updated:
- test-go.yml: ci-go:1.26 on both `test` and `integration` jobs.
- test-web.yml: ci-go:1.26 (bundles Node + npm); the
actions/setup-node@v4 step is removed.
- flutter.yml: ci-flutter:3.44 (Flutter 3.44 + Android + Java 25).
- release.yml: ci-go:1.26 (ships docker CLI + buildx).
Side effect: this unblocks the Go server deps bump (commit 6a62120)
which auto-bumped go.mod to `go 1.25.0` via x/crypto v0.51.0's
minimum — ci-go:1.26 satisfies it with headroom.
Adds ci-requirements.md at repo root per the ci-runners.md
"every project ships a requirements sheet" rule. Documents:
runtime images consumed, image deps used per workflow, per-job
installs (none), and a Notes section covering the integration
docker-socket dependency, the toolchain pin rationale, and the
in-app-update channel polling.
Tracked in local task #70.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`--filter name=integration` matched EVERY concurrent integration run's
Postgres service container. A dev push and the main-merge run overlap
on the shared act_runner daemon → 2 candidates → the "expected exactly
1" guard aborts (false failure; not a code defect).
Discover instead by intersecting networks: act_runner attaches the job
container and its service container to a shared per-job network, so
select the postgres that sits on a network this job container is also
on. The dev-compose container is skipped explicitly as before.
CI-only change; the released v2026.05.19.0 code is unaffected (a clean
re-run of the failed job passes — the failure was a concurrency race).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First CI integration run proved the act_runner pattern works (service
discovery, migrate, exactly-one guard all functioned) but ~150 tests
failed with `dbtest.ResetDB truncate: deadlock detected (40P01)` plus
cascading FK/dup-key symptoms. Root cause: `go test ./...` runs package
binaries concurrently (default -p = NumCPU); every integration package
TRUNCATEs the single shared minstrel_test DB, so concurrent truncates
deadlock and half-seeded fixtures violate FKs. The documented local
invocation is `go test -p 1 ./...` for exactly this reason. Serialize
package execution in both the CI step and `make test-integration`.
Genuine (non-concurrency) failures will remain after this — never caught
before because integration tests never ran in CI. Triaged next.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
#321 — `minstrel admin reset-password [-user admin] [-password X]`:
loads config, updates BOTH password_hash (bcrypt) and subsonic_password
(plaintext, for Subsonic t+s) so neither auth path is left stale;
generates+prints a strong password when -password is omitted. Recovers
a locked-out operator without DB surgery. Subcommand dispatch added to
main.go (os.Args switch before flag-parse; server path untouched) plus
a `minstrel migrate` subcommand exposing db.Migrate standalone.
#339 — integration tests no longer truncate the dev DB:
- deploy/initdb creates minstrel_test on a fresh compose volume;
`make test-integration` ensures it idempotently and points
MINSTREL_TEST_DATABASE_URL at minstrel_test.
- docker-compose.yml + README updated.
CI integration job (test-go.yml): the prior workflow only ran
`go test -short -race` with no DB, so the entire integration suite
silently t.Skip'd — "CI green" never covered API/db/scanner. New
`integration` job runs the full `go test -race` against an ephemeral
Postgres service, using the act_runner shared-daemon pattern: no
published ports, discover the service container by job-name filter via
the docker socket, reach it by bridge IP, hard exactly-one assertion +
dev-compose-name reject (a wrong target would truncate real data),
TCP-wait, `minstrel migrate`, then test. Fast `test` job kept as the
quick gate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The debug APK step dominated the run (~7m32s of ~10m) and ran on
every dev push, but the operator dev-tests via a local Android
Studio build, not the CI artifact. Gate the debug APK + its
artifact upload to main pushes only: dev = analyze+test+codegen
(~3min); main = + debug APK as the native-build safety net
(Gradle/manifest/plugin breakage analyze+test can't catch) before
any release tag; tags = signed release APK (unchanged).
Note: the bulk of that 7m32s was the flutter-ci runner image
re-installing NDK 28.2.13676358 + build-tools 35 + platform 35/36
+ cmake 3.22.1 every run (image baked platform-34/build-tools-34,
stale vs the bundled Flutter's requirements). Baking those into
CI-Runner/CI-flutter/Dockerfile is the larger win and also speeds
release builds — tracked separately (operator-side infra, not in
this repo).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Update installs were failing at the system scanner step because every
release APK was signed with a different signature: build.gradle.kts
fell back to signingConfigs.getByName("debug"), and the debug
keystore is generated per-machine — so every CI runner had a fresh
random key. Android refuses to upgrade an installed app when the
signature doesn't match, hence the "App not installed" failure
after the scan.
Two-part fix:
1. build.gradle.kts now defines a real "release" signing config when
ANDROID_KEYSTORE_PATH is exported (with the matching password +
alias env vars). Without those, falls through to the debug
keystore so local `flutter run --release` still works.
2. flutter.yml decodes ANDROID_KEYSTORE_B64 (CI secret, base64 of the
real release keystore) into a tmp path before the release-APK
build step, then exports ANDROID_KEYSTORE_PATH + the three
password/alias secrets as env vars. CI now hard-errors if the
keystore secret is missing on a tagged build — we don't want
another silent debug-keystore release.
OPERATOR ACTION REQUIRED before the next tag:
1. Generate a release keystore (one-time):
keytool -genkey -v -keystore minstrel-release.keystore \
-alias minstrel -keyalg RSA -keysize 2048 -validity 10000
2. Base64 it:
base64 -w0 minstrel-release.keystore > keystore.b64
3. In Forgejo, add four repo secrets:
ANDROID_KEYSTORE_B64 = contents of keystore.b64
ANDROID_KEY_ALIAS = minstrel
ANDROID_STORE_PASSWORD = the password you set
ANDROID_KEY_PASSWORD = same password (or different alias pwd)
4. Keep minstrel-release.keystore offline and backed up — losing it
means you can never sign an upgrade for any existing install.
5. Existing installs from prior debug-keyed releases must be
uninstalled before installing the first key-signed release. This
is a one-time transition; future tagged builds will upgrade
cleanly.
Update banner showing on identical versions:
- pubspec.yaml was stuck at the placeholder 0.1.0+1, so
PackageInfo.version returned "0.1.0" while the server reported the
actual release tag (e.g. "2026.05.10.1"). Comparison correctly said
"newer" → banner always showed.
- Bump pubspec to 2026.05.11.0+1 so the local default matches the
release cadence even before CI overrides it.
- Update flutter.yml release step to pass --build-name="${TAG#v}" so
every tagged APK reports the tag as its PackageInfo.version. Future
releases stop drifting from pubspec.
- Rewrite isVersionNewer to do component-wise int comparison with
zero-padding: pub_semver.Version.parse rejects 4-part date versions
like "2026.05.10.1", at which point the old code fell back to
string inequality and treated "2026.05.10" as newer than itself
vs "2026.05.10.0". Drop the pub_semver import (no longer used).
Lock-screen play/pause not responding:
- PlaybackState only listed MediaAction.seek in systemActions, which
on Android 13+ means tapping the lock-screen play/pause button
doesn't route back to the AudioHandler. Add play, pause,
skipToNext, skipToPrevious to the set.
- Add androidCompactActionIndices: [0, 1, 2] so the compact
notification view explicitly maps the three buttons.
Album art being smaller than the lock-screen frame is upstream of
this commit — the cover-cache writes whatever pixel dimensions the
server returns. If the server's /api/albums/<id>/cover returns small
thumbnails for these albums, the lock screen renders them at that
size. Worth a separate look at the server cover-emit path.
Came up debugging the in-app update flow — wasn't obvious which image
the container was actually running without exec'ing in. New flow:
### Server
- internal/server/version.go: new `var ServerVersion = "dev"`,
overridden via -ldflags at build time.
- /healthz response gains a "version" key alongside the existing
"status" + "min_client_version". Backward-compat: existing clients
ignore unknown JSON fields. Endpoint stays unauthenticated.
### Build
- Dockerfile: new `ARG MINSTREL_VERSION=dev`, threaded into the
go build -ldflags so the binary's ServerVersion is stamped at
link time. Default "dev" preserves local `docker build` ergonomics.
- .forgejo/workflows/release.yml: tags step also emits a `version`
output (the git tag for tag pushes, "main" for branch pushes);
build step passes it as `--build-arg MINSTREL_VERSION=...`.
### Web
- web/src/lib/components/ServerVersion.svelte: small understated
text ("Server v2026.05.10.2") that fetches /healthz on mount.
Renders nothing on parse failure or pre-version images.
- Mounted at the bottom of Settings.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Both prior secrets did related work (one for registry push, one for
release asset I/O) and required separate Forgejo PATs to manage.
Replacing with a single CI_TOKEN keyed off a single PAT with the
union of scopes (write:repository + write:package).
- flutter.yml: APK attach step → CI_TOKEN
- release.yml: docker login → CI_TOKEN; APK fetch step → CI_TOKEN
No behavior change — same calls, single secret name. Operator needs
to set CI_TOKEN in repo settings (Actions → Secrets) with a PAT that
has write:repository + write:package; the prior REGISTRY_TOKEN /
RELEASE_TOKEN secrets can be removed.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Final phase of the in-app update flow. release.yml on tag pushes
fetches the APK that flutter.yml is attaching to the same release,
drops it into client/ in the build context, and the Dockerfile's
COPY client/ /app/client/ bakes it into the image.
### How it sequences
flutter.yml and release.yml both trigger on tag pushes and run in
parallel on different runners (flutter-ci vs go-ci). flutter.yml
typically finishes APK build + release attachment in 2-5 min.
release.yml polls the release page for up to 15 min for the APK to
appear, then proceeds. If the APK never lands (flutter.yml failure,
network hiccup), release.yml emits a warning and ships the image
without the bundled APK — server returns 404 from /api/client/version,
banner stays hidden, manual download from the release page still
works. Graceful degradation, not a blocker.
### Repo shape
- client/.gitkeep + client/README.md so the directory exists in git
and the COPY in the Dockerfile always finds something to copy
- .gitignore excludes client/minstrel.apk + .version so accidental
commits don't bloat the repo
- Dockerfile: COPY --chown=minstrel:minstrel client/ /app/client/
### Why polling vs cross-workflow trigger
Forgejo Actions' workflow_run support varies by runner version; the
polling approach is universally compatible. If/when we standardize on
a runner that handles workflow_run cleanly, the polling step can
become a `needs:` dependency.
Closes#397.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Forgejo Actions cache server at 172.18.0.27:41161 isn't reachable
from the test-web runner container; setup-node sat there waiting for
ETIMEDOUT each run. Drop `cache: 'npm'` so the step finishes in seconds.
`npm ci` still works deterministically from package-lock.json — net cost
is ~10-30s of registry fetch vs. 4m41s of timeout. Restore the cache
option once the runner-host network reaches the cache server (separate
operator task).
Operator wants CI to run on dev pushes (not just PR-to-main) but
path-scoped so Go-only diffs don't run web tests and vice versa. The
old test.yml ran everything on PR-to-main only; the new shape is two
focused workflows that each path-filter their own scope.
- test-web.yml — paths: web/**. Runs npm ci + npm run check + vitest.
Drops the npm run build step (vitest doesn't need the bundle; the
go:embed placeholder lives in web/build/index.html and never needs
the test job to rebuild it).
- test-go.yml — paths: **/*.go, go.mod, go.sum, sqlc.yaml, internal/**,
cmd/**. Runs go vet + golangci-lint + go test -short -race.
Both trigger on push to dev/main and PR to main. Tag pushes are not
covered — release.yml owns the tag-build path and tests have already
passed by the time a tag lands.
Drops the gomod-detect guard from test.yml — go.mod has been present
since M1 and is required for any Go file to exist anyway.
The flutter-ci runner image (CI-Runner/CI-flutter/Dockerfile) bakes in
Flutter 3.41.8 + Android cmdline-tools + platform-34 + build-tools
34.0.0 + JDK 17, so the workflow no longer needs subosito/flutter-action
to install everything per-job. Drops the setup step and switches
runs-on from the general-purpose go-ci to flutter-ci.
Per project memory feedback_dedicated_runner_labels.md: prefer
purpose-built labels with toolchains pre-installed over generic-runner +
setup-action ceremony on this self-hosted Forgejo deployment.
ubuntu-latest isn't a label any runner in this Forgejo deployment
advertises. The existing test.yml + release.yml both target the
project's go-ci label; flutter.yml should match. subosito/flutter-action@v2
installs the Flutter SDK on whatever runner picks up the job, so
go-ci is fine even though it isn't Flutter-pre-installed.
Triggers on push to dev/main, tag pushes, PR to main, and manual
dispatch — all path-filtered to flutter_client/** and the three
shared web inputs the sync_shared.sh script reads.
Steps:
- Sync tokens/error-copy/svg from web/ via tool/sync_shared.sh
- Re-run dart run tool/gen_tokens.dart and fail if lib/theme/tokens.dart
drifts from shared/fabledsword.tokens.json (catches forgotten regen
on the JSON edit path)
- flutter pub get / analyze --fatal-infos / test
- Debug APK on every push (uploaded as a workflow artifact)
- Release APK on tag, attached to the corresponding Forgejo release
via RELEASE_TOKEN (release.yml creates the release entry; this
workflow just attaches the APK as minstrel-<tag>.apk)
Uses subosito/flutter-action@v2 on ubuntu-latest for portability —
no dependence on a Flutter-pre-installed runner.
The repo now contains the Flutter mobile client at flutter_client/
(M7 #356). Two cleanups so the existing build pipelines don't churn
on Flutter-only changes:
1. .dockerignore — keep the Flutter project (and docs/, IDE noise,
git metadata) out of the Docker build context. The runtime image
was already unaffected (multi-stage drops everything but the Go
binary), but the COPY . . layer cache invalidated on every
Flutter edit. Build context shrinks ~2.4 MB and Flutter-only
pushes no longer force Go rebuilds.
2. test.yml + release.yml — paths-ignore on flutter_client/**,
docs/**, and **/*.md. Go/web tests + container build now skip
when the diff doesn't touch them. Tag releases still build broadly
since server + Flutter ship paired.
The Flutter-side workflow lands in M7 Task 21 with its own paths
filter restricting it to flutter_client/** and the shared web/
inputs (tokens.json, error-copy.json, album-fallback.svg).
Forgejo Actions fired both `push` and `pull_request` events for the same
commit when pushing to dev with an open PR — doubled CI runs on every PR
commit (e.g. #182 and #183 on PR #24's HEAD `95d68e3`). Drop the push
trigger entirely; PRs against main are the only quality gate that
matters in this workflow (dev → PR → main, never direct push to main).
Trade-off: direct pushes to dev with no open PR no longer get CI on
their own. Acceptable — the moment the PR opens, the pull_request event
fires and runs the same workflow.
Go's //go:embed needs web/build/ to exist at compile time. CI now
runs 'npm ci && npm run build && npm test' ahead of the Go steps
so the embed directive sees real, freshly-built assets.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The default GITHUB_TOKEN provided by Forgejo Actions lacks write:package
scope, so docker buildx push failed with 401 reqPackageAccess. Swap in
the repo-level REGISTRY_TOKEN secret (a PAT scoped write:package) for
docker login; github.actor still supplies the username.
Also drops the transient Docker environment diagnostics step — the
registry was the issue, the socket/buildx setup is fine.
Adds a manual-trigger hook so we don't need a fresh commit to re-run
this pipeline, and dumps docker/buildx state before the build so CI
failures are diagnosable without docker.sock guesswork.
bvandeusen