ci(openemr-cmd): add arm64-smoke-e2e on ubuntu-24.04-arm (daily-cron + workflow_dispatch)#845
Conversation
…+ workflow_dispatch) Replaces the abandoned macos-smoke attempt (openemr#844, closed). The macOS path hit a fundamental wall on free GH-hosted runners — macos-14 arm64 can't run Linux VMs reliably (VZ requires nested virtualization which isn't available; QEMU panics in Lima's host agent with abort traps). After 4 iterations of trying to make colima work, pivoted to arm64 Linux runners instead. ubuntu-24.04-arm gives us the actual signal we wanted: arm64- specific image regressions in openemr/openemr:flex (the image is multi-arch — Docker auto-selects the arm64 manifest on arm64 hosts). Apple Silicon Mac developers pull the arm64 variant via Docker Desktop's Linux VM; catching arm64-only image bugs here within 24h saves them from finding the regressions first. Linux arm64 runners use native cgroups/namespaces on an arm64 host kernel — same fast/supported path as ubuntu-22.04 for amd64, just on arm64. Zero virtualization, no colima brittleness, comparable wall-clock budget to the existing nonworktree-lifecycle-e2e job (~15 min healthy + ~10 min for setup/smoke/teardown = ~25 min outer). What this catches that amd64-only doesn't: - Image regressions specific to arm64 (e.g., arm64-only segfault in apache, missing arm64 native deps, etc.) - HOST_UID entrypoint adoption working in the arm64 image variant (verified by the bind-mount ownership assertion) What this does NOT catch (out of scope): - macOS-specific concerns: HFS+/APFS case-insensitivity, BSD coreutils edges, Docker Desktop bind-mount semantics. Most of these are covered at the script level by the bats portability memory note; the rest are "would be nice if a contributor reports a bug" rather than CI requirements. Triggers: schedule + workflow_dispatch only. Skipped on PR/push so cycle stays fast. TEMPORARY in this PR: pull_request also triggers, so we can validate end-to-end on an arm64 runner before merge. Pre-merge cleanup: drop the pull_request clause from the if-guard so the job becomes truly schedule-only. Assisted-by: Claude Code
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds an ChangesArm64 smoke workflow
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/test-bats-openemr-cmd-real-docker.yml:
- Around line 43-48: The workflow comments/docs are out of sync with the actual
trigger behavior: the ARM smoke job is no longer PR-skipped because
`pull_request` is intentionally enabled in the workflow definition. Update the
descriptive comments and any related job names/labels around `arm64-smoke-e2e`
and the workflow trigger section to match the temporary PR trigger, and remove
or reword any “daily-cron only” / PR-skipped wording so it reflects the current
`pull_request` + scheduled/manual behavior.
- Around line 1737-1748: Both checkout steps are using the floating
actions/checkout@v7 tag, which violates the workflow pinning policy. Update each
actions/checkout reference in this job to a specific full commit SHA so the
openemr-devops checkout and the later openemr/openemr checkout are both
immutable and not affected by tag retargeting.
- Around line 1833-1835: The cleanup step for openemr-cmd is not actually
running the volume-removal path it advertises, so update the teardown command in
the workflow step named openemr-cmd down -v (cleanup) to include the -v flag.
Make the change in the openemr-cmd down invocation so the job genuinely
exercises the full down -v cleanup contract.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 4a5626ae-0a49-490c-979a-dbaac4840167
📒 Files selected for processing (1)
.github/workflows/test-bats-openemr-cmd-real-docker.yml
…dress rabbit Three changes per user direction + CodeRabbit: 1. Drop the schedule-only `if:` guard. The job ran on PR (via the temporary trigger) in ~10 min and passed cleanly — cheap enough to gate every PR on. Aligns with the other 5 e2e jobs which all run on push/pull_request without restriction. 2. Update top-level comment + job comment to reflect "runs on every PR" instead of "daily-cron only". The pre-merge banner in the PR description called this out; cleanup happens here. 3. Step name "openemr-cmd down -v (cleanup)" → "openemr-cmd down (cleanup — internally -v)" with inline note. The behavior is already correct (cmd_down dispatch calls `docker compose down -v` under the hood); rename clarifies the step matches the user-facing command, not the internal flag. CodeRabbit's SHA-pin thread on actions/checkout@v7 stays open as the repo-wide convention is tag-pinned (every other job uses @v7). Separate policy decision; replying on the thread. Assisted-by: Claude Code
Summary
Replaces the abandoned macOS smoke attempt (#844, closed) with an arm64 Linux runner. Adds one nonworktree-style stack on
ubuntu-24.04-armto validate the openemr image's arm64 manifest works end-to-end.Why arm64 Linux instead of macOS
Free GH-hosted
macos-14(Apple Silicon arm64) fundamentally can't run Linux VMs reliably on the free pool — VZ driver needs nested virtualization (not available), QEMU panics in Lima's host agent with abort traps. After 4 iterations trying colima/Lima, abandoned the macOS path.ubuntu-24.04-armgives us the same signal we actually wanted: arm64-specific image regressions. The openemr image is multi-arch (amd64 + arm64). Docker auto-selects the arm64 manifest on arm64 hosts. Apple Silicon Mac developers pull the arm64 variant via Docker Desktop's Linux VM, so catching arm64-only image bugs here within 24h saves them from finding them first.Linux arm64 runners use native cgroups/namespaces on an arm64 host kernel — same fast/supported path as
ubuntu-22.04for amd64, just on arm64. Zero virtualization, no colima brittleness.Scope (intentionally narrow vs the amd64 jobs)
One stack, one health check, one HTTP smoke, one bind-mount ownership assertion, one teardown. Heavier arm64 coverage can be filed if this smoke ever catches a real regression.
What this catches that amd64-only doesn't
openemr/openemr:flex(missing arm64 deps, arm64-only segfaults, etc.)What this does NOT catch (out of scope)
Cost
~25 min outer timeout. Public-repo arm64 runners are free as of mid-2024.
Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit