Repository navigation
Fix the unit test job: run the display cutout test on the same SDK as the rest - #6855
Conversation
`DisplayCutoutPaddingTest` is the only Robolectric test in the suite pinned to SDK 31; the other twelve all run on 33. That makes the run fetch a second `android-all` jar, and the download of that one has been failing on CI since the test landed, taking the whole suite down with it in `initializationError` before any assertion runs. Nothing in the test depends on 31. Window insets are dispatched the same way on both levels, so the behaviour under test is unchanged. Assisted-by: Claude Code:claude-opus-5 Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to This change only selects SDK 33 for the display-cutout test. No supported evidence shows a merge-blocking regression, so it is ready for normal checks. Pre-merge checks |
  |
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Docstring Coverage |  |
Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files. | Write docstrings for the functions missing them to satisfy the coverage threshold. |
✅ Passed checks (4 passed)
-
Check name Status Explanation Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Title check The title clearly states that the display cutout test will use the same SDK as the other unit tests. It accurately describes the main change. Description check The description provides detailed failure context, explains the cause and scope of the change, reports local verification, and includes the checklist. The omitted Screenshots and TODO sections are not…
- Fix all pre-merge checks with AI
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
📱 QA build
The QA build installs alongside a released Nextcloud app, so you can keep Downloading the file requires a GitHub account, so open this link on the |
2 participants
master's unit test job has been failing since 2026-10-07, and every pull request opened since inherits it. The last green run wase75dbd27e; everything after it is red, which is long enough that the failure now reads as background noise rather than a broken build.Robolectric does not take its
android-alljars through Gradle; it downloads one per distinct SDK level the suite asks for, straight from Maven Central, the first time a test needs it. This suite asks for exactly two levels: 33, used by twelve tests, and 31, used only byDisplayCutoutPaddingTest. The jar for 33 downloads fine — those twelve tests run. The one for 31 dies in the TLS handshake, and because it dies while the runner is still initialising, it surfaces asinitializationErrorwith no assertion in the log to point at. That is why it looks like a flake. It is not: it has failed nine runs in a row, and in under a minute each time.Nothing in the test depends on 31. It dispatches a
WindowInsetsCompatcarrying adisplayCutout()inset and asserts the resulting padding;WindowInsetsCompatis a Jetpack compat shim that dispatches identically on both levels, and display cutouts are API 28+, so both are well clear of the floor. Every other Robolectric test in the repository already uses 33. Running on 33 means the suite needs only the jar it already fetched successfully, so there is no second download to fail.Verified locally: both assertions pass on 33 (
BUILD SUCCESSFUL).This does not repair the underlying TLS failure — Conscrypt's X25519 key generation, from
conscrypt-openjdk-uberon the test classpath — it removes the second download that trips over it. Adding a thirteenth SDK level later would bring the problem back. #6854 attacks the same problem from the other side by caching the jars, but it cannot help until a run goes green first, sinceactions/cacheonly saves on success. This one has to land first.🏁 Checklist
/backport to stable-xx.x🤖 AI (if applicable)