Repository navigation
ci: check Postgres health as the postgres role and version the AVD cache key - #142
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe Android workflow now includes emulator and system-image revisions in the AVD cache key. The CI workflow now specifies the PostgreSQL user for its health check. ChangesAndroid emulator cache
PostgreSQL health check
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix · Severity of issue fixed: Low Suggested reviewers: Merge Risk: ⚪ Minimal · up to The Android cache key distinguishes emulator and system-image revisions, and CI checks PostgreSQL readiness as the configured user. No concrete merge-blocking risk is evident. Pre-merge checks |
|
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. 🤖 Generated with Claude Code |
aaronbrethorst
left a comment
There was a problem hiding this comment.
Both fixes are right. pg_isready -U postgres matches the role the service creates, and putting the emulator and image versions in the AVD cache key keeps stale snapshots from being restored. Thanks.
Fixes #141.
Two CI follow-ups from review.
The Postgres service's health check ran plain
pg_isready, which connects as thecontainer's root user, so every ci job logged
role "root" does not exist. It nowruns
pg_isready -U postgres, the same command docker-compose.yml uses.The AVD cache key was
avd-<api level>-<target>-<arch>. The emulator actiondownloads the emulator and the system image on every run, so once either one was
updated, the job could restore a snapshot made with the old version against the
new one. The job now installs both before the cache step, reads each package's
Pkg.Revisionfrom its source.properties, and puts both versions in the key. Ifeither version can't be read the step fails, because an empty value would quietly
bring the stale-snapshot problem back.
yesis wrapped as(yes || true)so itsSIGPIPE exit can't fail the install step if the job ever runs with pipefail, as
the iOS workflow does.
I ran the version step's exact script against a local SDK: it read emulator
36.6.11 and image 4, and with an image that isn't installed it exits 1 and writes
no outputs. Both workflows parse, and the version step runs before the cache step.
This PR's first instrumented run will miss the cache once, since the key changed,
and regenerate the snapshot. That is expected.
Not in this PR: making
instrumenteda required check, which is abranch-protection setting.
Summary by CodeRabbit