fix(ci): find server logs under the testing cache root, never fail on absence - #962
Conversation
… absence The 'aw-server-rust master' matrix leg has failed on every PR since the aw-server-rust nightly picked up ActivityWatch/aw-server-rust#652 (named instance profiles, merged 2026-08-31). That change resolves the cache root via appname(): a --testing server on a machine with no legacy testing data now logs under ~/.cache/activitywatch-testing/, not ~/.cache/activitywatch/. GitHub runners are fresh, so the nightly leg writes to the new root while the pinned v0.12.3b18 legs (pre-ActivityWatch#652 binaries) still use the old one - exactly the observed pass/fail split. Glob both roots so the diagnostics come back, and guard with nullglob so these always()-gated log steps can no longer fail the job when no logs exist. A diagnostic step should never gate a merge. Git-Session-Id: f31d
Greptile SummaryThis PR repairs CI server-log collection after testing-profile logs moved to a profile-specific cache root.
Confidence Score: 5/5The PR appears safe to merge, with the previously failing no-log path now handled successfully. Each matrix leg launches a single ActivityWatch server on a fresh runner, and the revised Bash steps correctly collect its log from either supported cache root or exit successfully when no matching log exists. Important Files Changed
Reviews (1): Last reviewed commit: "fix(ci): find server logs under the test..." | Re-trigger Greptile |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #962 +/- ##
=======================================
Coverage 49.62% 49.62%
=======================================
Files 46 46
Lines 2783 2783
Branches 630 630
=======================================
Hits 1381 1381
Misses 1322 1322
Partials 80 80 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
CI-green and mergeable — waiting only on a maintainer click. This PR is ready to merge, but the bot has pull-only access to this repo and can't self-merge — surfacing it here so it isn't lost. The monitoring loop will stop re-flagging it now that this note is posted. |
|
CI green on this PR, including the Confirmed the diagnostics are actually restored, not just silenced — the master leg now prints and uploads a real log: The |
The
Test (node-20, py-3.9, aw-server-rust master)matrix leg is failing on every PR right now (e.g. #960, #961). The tests themselves pass — the job dies in the post-test log-collection steps:Root cause
ActivityWatch/aw-server-rust#652 (named instance profiles, merged 2026-08-31) changed
get_user_log_dir()from a hardcodedactivitywatchroot toappname():appname()returnsactivitywatch-<profile>unless the profile isdefault, or unless it istestingand legacy testing data already exists on disk. GitHub runners are fresh, so there is no legacy data andaw-server --testingnow logs under~/.cache/activitywatch-testing/.That explains the exact pass/fail split we see: the
masterleg runs the nightly (post-#652) binary and fails, while thev0.12.3b18legs run released pre-#652 binaries and still pass.Fix
~/.cache/activitywatch*/log/*/*.logso both roots are covered — this restores the diagnostics, which have been silently missing (No files were found with the provided path: logs/dist/*) rather than merely unblocking the job.nullgloband an explicit empty check so thesealways()-gated steps exit 0 when there is nothing to collect. A diagnostic step should never gate a merge.No behavior change when logs are present.
Verification
The glob/
nullgloblogic was exercised locally for both the empty case (prints a notice, exits 0) and the both-roots case (finds logs underactivitywatch/andactivitywatch-testing/). Since this is apull_requestworkflow, CI on this PR runs the patched file — theaw-server-rust masterleg going green here is the real test.