tooling: recordRoborazziDebug from a worktree writes baselines into the primary checkout
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Domain
- build-system, tooling
Research direction
Start with the recordRoborazziDebug task in the :android:app Gradle setup, where the baseline output path is configured, and reproduce with HomeScreenshotTest.whatsNew from a git worktree with and without --no-configuration-cache. Then read worker-finish.sh to see why --record-screenshots is rejected alongside --no-test. Done means the baseline lands in the worktree under the configuration cache and the script accepts both flags together.
Written by the indexing model from the issue text.
Description
Re-recording a screenshot baseline from a worker worktree writes the PNG into the primary checkout's docs/ instead of the worktree's.
How it was seen: while re-recording HomeScreenshotTest.whatsNew in the worktree, the worker ran ./gradlew :android:app:recordRoborazziDebug --tests '*HomeScreenshotTest.whatsNew' there. The new baseline landed in the primary checkout. With --no-configuration-cache it went to the worktree as expected. The likely cause is that the configuration cache keeps the Roborazzi output path as an absolute path (unverified).
There's a second problem: worker-finish.sh --record-screenshots can't be combined with --no-test. So a baseline-only change can't go through the normal finish path, and the recording would hit the same path problem anyway.
Fix: make the baseline output dir relative to the project, or not part of the config-cache inputs. Also let --record-screenshots work with --no-test.
Impact U1 (workers write into the primary checkout, and re-recording baselines needs a manual workaround) · Reach R2 (every worktree screenshot re-record; seen once) · Implemented: no · Design fit: fits · Complexity: S
- Dominant language
- Kotlin
- Stars
- 229
- Forks
- 28
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from timusus/Shuttle2
-
bug design impact:U1 P3 reach:R2 size:S
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
enhancement impact:U1 later P3 reach:R2 size:S
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
impact:U1 owner reach:R1 size:S
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 3/5 Half a day Newbie friendliness 68/100
-
Difficulty 3/5 Half a day Newbie friendliness 55/100
All issues in timusus/Shuttle2
Similar issues
-
bug follow-up
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
binding:web core docs p3
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
RunanywhereAI/runanywhere-sdks#1123 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
openai/openai-java#1202 ·
Maintainers usually reply within 1 day
-
StepExamBenchmarkTest runs a loop and prints a timing but asserts nothingPossibly taken A pull request linked to this issue is open or already merged. Openjules
Difficulty 1/5 Under an hour Newbie friendliness 82/100
open-learning-exchange/myplanet#18199 · 1 comment ·
Maintainers usually reply within 4 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
auth0/Auth0.Android#1095 · 1 comment ·
Maintainers usually reply within 1 day