Repository navigation
Name the repository root apart from the Gradle root (#519) - #524
Merged
Merged
Conversation
…y shared or iOS path through it The Gradle builds read and write the Swift manifests, the iOS fixtures, docs/, config/, LICENSE, CHANGELOG.md, third-party/ and devicelab/, and each of those paths assumed the Gradle root was the repository's. One Gradle property, superplayer.repositoryRoot in the root gradle.properties, now names it; the root build and its modules read it through build-logic's repositoryRoot, the root settings through providers, demo/ and benchmark/ from the root build's gradle.properties, and build-logic's tests through repositoryRootOf. The two roots are one directory today, so nothing moves; moving the Android builds under android/ (#521) is that one line becoming `..`. Closes #519 Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01MJAhQmFgdRRAKUaMHibQLe
…rk the two settings copies as copies, and scope the one-line claim Co-Authored-By: Claude Opus 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01MJAhQmFgdRRAKUaMHibQLe
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #519
The Gradle builds read and write the repository's own files: the Swift manifests, the iOS fixtures,
docs/,config/,LICENSE,CHANGELOG.md,third-party/anddevicelab/. Every one of those paths assumed the Gradle root was the repository root. This PR names the repository root once and resolves each of those paths through it.The two roots are the same directory today, so no file moves and no behaviour changes. In #521, moving the four builds under
android/changes one line on the Gradle side:superplayer.repositoryRoot=.becomes...Decisions
The mechanism: one Gradle property in the root
gradle.propertiesThe property is
superplayer.repositoryRoot. It is a path from the root build's directory to the repository root.Four builds need the value, and they cannot share code:
demo/andbenchmark/. They are separate builds and never load build-logic.All four can read one properties file, so the value is written once and each build derives its own copy from it:
Project.repositoryRootin the newbuild-logic/.../RepositoryRoot.kt. It reads the value throughproviders.gradleProperty, so the configuration cache tracks it. It refuses a missing value by name. It also refuses a value naming a directory that does not contain the build, because a typo would otherwise show up as "file missing" rather than "file misplaced".providers.demo/andbenchmark/settings: load../gradle.properties, the same way they already load../gradle/libs.versions.toml. They hand the value to their build script throughgradle.extra. The two blocks are marked as copies of each other.repositoryRootOf(File("..")), which is the same resolution the plugins use. I chose this over the suggested system property: a second channel could disagree with the first, and this way the tests exercise the plugins' own code path.docs/(TelemetrySchemaDocumentTest,DoctorDocumentTest,TransportDocumentTest): they get a module-relativesuperplayer.repository.dirsystem property from the convention plugin. This follows the existingsuperplayer.golden.dirpattern.Paths deliberately left on the Gradle root
The catalog,
settings.gradle.kts,superplayer-*,api/releasedand the Spotless targets stay where they are, since they are the Gradle build's own files.CutReleasegitnow runs at the repository root, the one directory that contains every path a release writes.git addpaths are no longer a fixed list.releaseWrittenPathscomputes them relative to the repository root, givingandroid/gradle/libs.versions.tomlandCHANGELOG.mdonce the roots differ.publishToMavenLocalstill runs at the Gradle root, wheregradlewis.convertThroughputTraceRelative
--inputand--outputpaths now resolve against the repository root, not the invoking directory. Three reasons:StartParameter.currentDir, moves with-p.docs/are written from, and it stays the same however the wrapper is reached.Tests
RepositoryRootTesthas seven cases:..: the value is honoured..: resolves to the build's own directory.LicenseHeaderTest,ModulePhaseRuleTestandCompatibilityDocumentTestnow read the documents and Swift files under the repository root, and read the modules and settings under the Gradle root.Verification
./gradlew assemble check --max-workers=1: green, run before and after the review fixes. The XML results show 1238 tests with 0 failures and 0 errors across the module unit tests and build-logic../gradlew updateIosFixturesrun on its own:git status --short ios/is empty, so the fixtures are byte-identical.publishToMavenLocal, then(cd demo && ./gradlew assembleDebug spotlessCheck)and(cd benchmark && ./gradlew assemble spotlessCheck): both green.ios/checkwas not run, because nothing in Swift changed. No emulator run was needed either: this changes the build's paths, not playback.Review
Standards
No hard findings. I fixed these soft ones:
.get().superplayer.repository.dirsystem property now names the Gradle property it comes from.RepositoryRoot.ktis scoped to the four builds moving together.RepositoryRootTest's KDoc now says why the release-path cases live there.Left as they are:
REPOSITORYlookup. There is no shared test module across phases to put it in.Spec
No gaps. Minor points:
-Poverride would reach the root build but notdemo/,benchmark/or the build-logic tests, which read the file directly. That is an edge case, and nothing here passes-P.RunConditions.read(repoRoot, …)actually receives the Gradle root. It uses it for the catalog and forgit, and both keep working after the move. Only the name and KDoc become inaccurate, so I left them for Move the Android builds under android/ #521 or Documents describe the android/ layout #522 rather than widening this PR.Skipped and why
.claude/worktrees/**exclude: left for Move the Android builds under android/ #521.benchmark/benchand.github/: these belong to Scripts and CI find the Gradle build through one location #520.🤖 Generated with Claude Code
https://claude.ai/code/session_01MJAhQmFgdRRAKUaMHibQLe