Grant all permissions in the E2E onboarding flow - #5620
Conversation
They ended up on the failure report added next to them, where the input is ignored, so every run uploaded nothing and failed on the missing path.
Covers what people actually tap, and reaches the home network step, which the flow skipped entirely before: choosing the less secure local access level settles the decision on the spot and jumps to completion, so it was never the denial that skipped it. Taps that open or dismiss something now repeat until that has actually happened. A tap aimed at a screen still animating in lands on the backdrop behind it and is swallowed, while the tap itself reports success, which is what left the notification sheet and the sidebar sitting untouched.
There was a problem hiding this comment.
🟡 Changes recommended
The updated E2E UI test has a verified flaky/incorrect timeout fallback for in-app system alerts (and a couple of smaller issues) that can cause intermittent failures or unnecessary delays.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR stabilizes the nightly onboarding E2E workflow by (1) fixing artifact upload configuration so logs/recordings are actually captured, and (2) making the UI test flow closer to real user behavior by granting permissions and retrying taps that can be swallowed during UI transitions.
Changes:
- Fix the E2E workflow artifact upload by moving
pathback onto theactions/upload-artifactstep. - Update the onboarding E2E test to grant (rather than deny/skip) location and notification permissions, and to select the “most secure” local access option so the home network step is exercised.
- Add retry-based helpers for dismissing transient UI and for tapping web elements until their expected UI effect is observable.
File summaries
| File | Description |
|---|---|
| Tests/UI/OnboardingE2ETests.swift | Adjusts the E2E onboarding flow to grant permissions and adds retry helpers to reduce flakiness from swallowed taps. |
| .github/workflows/e2e.yml | Fixes artifact upload by attaching path to the correct upload-artifact step. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 3
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
The sheet is posted a few seconds after the frontend paints, so waiting for that first keeps a missing sheet from costing the whole frontend budget. Also drops a doc comment left behind by a helper that is gone.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5620 +/- ##
=======================================
Coverage 33.52% 33.53%
=======================================
Files 993 993
Lines 72598 72598
=======================================
+ Hits 24342 24344 +2
+ Misses 48256 48254 -2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
AI Policy
Select exactly one option that describes AI usage in this contribution:
Summary
Fixes the E2E workflow's artifact upload. The paths ended up on the failure report step added next to them, where the input is ignored, so every run failed on a missing
pathand saved nothing.Onboarding now grants every permission rather than skipping and denying them. That covers what people actually tap, and it reaches the home network step, which the flow had never run: choosing the less secure local access level settles the decision on the spot and jumps to completion, so it was that choice rather than the denial that skipped it.
Taps that open or dismiss something now repeat until that has actually happened. A tap aimed at a screen still animating in lands on the backdrop behind it and is swallowed, while the tap itself reports success, which is what left the notification sheet and the sidebar sitting untouched and failed the run later somewhere unrelated.
Screenshots
Not a user-facing change.
Link to pull request in Documentation repository
Documentation: home-assistant/companion.home-assistant#
Any other notes
The flow relaunches the app before opening settings from the frontend. Asking for that screen in the session that just onboarded crashes the app inside SwiftUI's navigation, which reproduces on iOS 26.5 and 27 and is worth its own fix; the relaunch keeps this test on its own subject until then.
Verified on CI and by three consecutive local runs against a real Home Assistant.