The builds page at /builds/ was empty because generate-build-history
only ran inside deploy-playstore; if that job failed early (e.g. Play
Store secrets not configured) the website was never updated, and the
build-linux job never triggered a website update at all.
Changes:
- generate_build_history.py: extend to cover Linux tarballs in addition
to Android APKs, capped at MAX_BUILDS_PER_PLATFORM (30) each
- Taskfile: add website-publish task (generate-build-history +
website-deploy), exclude *.tar.gz from rsync, update descriptions
- .forgejo/workflows/ci.yml: add publish-website job that waits for
both build-linux and deploy-playstore (using always() so it runs
even when deploy-playstore fails), then removes the duplicate
generate/deploy steps from deploy-playstore
- .github/workflows/ci.yml: add deploy job that deploys Linux build,
generates build history, builds Hugo site, and rsyncs to server
- .gitignore: ignore website/content/builds/_index.md (generated),
Python __pycache__, and widget test failure screenshots
- stalwart-dev/integration_ui_test.sh: use ${USER:-$(id -un)} for
robustness in environments where USER is unset
- scripts/test_generate_build_history.py: unit tests for parse_builds
and render_entries covering both platforms
Generated content (builds/_index.md and per-day pages) is not tracked
in git; it is produced at CI time and rsynced to the server.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
With set -Eeuo pipefail, a failing fvm flutter test exited the script
before _e2e_exit=$? could run, so the retry-on-new-display logic never
fired. Use the cmd || var=$? pattern to capture the exit code safely,
and add || true to the break guard so set -e doesn't trip on it.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The U7 onboarding view replaced "No accounts yet." with "Welcome to
SharedInbox", causing the E2E test to spin for the full timeout budget
(pumping slowly in headless CI) before failing. Fix the finder and
bump per-attempt timeout from 240s → 360s and CI job ceiling from
20 min → 30 min to give the full account-add → send → verify flow
room to complete.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
xvfb-run catches SIGTERM from `timeout`, kills its children, and exits 0,
making a timed-out test indistinguishable from a pass (CI #168 false positive).
Running Xvfb ourselves captures fvm flutter test's real exit code so timeouts
(exit 124) are correctly treated as failures.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Previous failed CI runs leave orphan sharedinbox/flutter processes that hold
onto Xvfb display resources, causing the next run's GTK app to hang during
initialisation (never connects back to the flutter test runner, no output
for 9+ min until timeout fires).
Fix:
- Kill stale sharedinbox/flutter processes before launching xvfb-run
- Retry the xvfb-run call once (4-min timeout per attempt) so a transient
display-init hang doesn't permanently fail the job
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sequential CI steps leave the runner under heavier load than the parallel
task check approach, so the E2E test can legitimately take 4-5 min.
Raise timeout 300→600 in integration_ui_test.sh and step timeout 6→12 min.
Job-level ceiling raised to 30 min to match.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Split single 'Run Full Check Suite' step into named steps so per-step
timing is visible in the CI UI
- Add timeout-minutes: 20 to the overall job and timeout-minutes: 6 to
the UI E2E step — previously a stuck xvfb-run could hang for 23+ min
- Add 'timeout 300' to xvfb-run in integration_ui_test.sh so the E2E
test exits with a clear error instead of hanging indefinitely
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
xvfb-run --auto-servernum picks a fresh display number, but if a previous
session left an orphan Xvfb process (e.g. killed mid-flight), the stale
/tmp/.X11-unix/X<N> socket and X<N>-lock still belong to that orphan, and
xvfb-run's cleanup at the end fails with "kill: No such process" — flipping
the script's exit status to non-zero even when the integration test itself
passed. Reap orphan Xvfb processes (pgrep -u $USER -x Xvfb) and remove their
display sockets and lock files before invoking xvfb-run.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Android UI integration test failed at tap(aliceTile) with "0 widgets"
even though pumpUntil had just found the tile. On the slow software-rendered
emulator the route-pop animation finalises during pumpUntil's trailing 300 ms
settle, briefly leaving the tile out of the tree. Re-confirm with a second
pumpUntil before the tap.
Bundles the previously uncommitted infra changes that make task deploy-android
run end-to-end inside nix develop: Linux desktop runtime libs + GL software
rendering env in flake.nix, path_provider_android pin to <2.3 to avoid the
libdartjni SIGSEGV, deferred DB-path resolution after WidgetsFlutterBinding,
+iglx for xvfb-run, platform-tools on PATH, and a single pre-commit script
replacing the dart-format / task-check-fast pair.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Stalwart 0.14.x does not increment HIGHESTMODSEQ when new mail arrives
via SMTP delivery, so the incremental sync's CONDSTORE fast-path saw
serverModSeq == storedModSeq and returned early — silently skipping
UID SEARCH and missing any newly received messages.
Fix: remove the early-return fast-path. Incremental sync now always
runs UID SEARCH UID ${lastUid+1}:* to discover new messages. CONDSTORE
is still used for the flag-refresh gate (only runs when modseq changed),
which is its correct, narrower role.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Fix HOME override that caused FVM to re-download 220MB Flutter SDK on
every run; use XDG_DATA_HOME instead to isolate app data without
touching HOME
- Switch DB path from getApplicationDocumentsDirectory() to
getApplicationSupportDirectory() so XDG_DATA_HOME isolation works and
stale accounts don't leak between test runs
- Replace fixed pump(5s/3s) waits with pumpUntil() polling at 200ms so
tests stop waiting as soon as the UI is ready (23s of dead wait → 8s)
- Add timing instrumentation (ts() in shell, _log()/Stopwatch in Dart)
- Fix CI integration-ui job: was mixing subosito flutter with fvm flutter;
now uses fvm consistently with actions/cache for ~/.fvm, ~/.pub-cache,
and build/linux
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
