What happened?
main does not compile. ComputingUnitManagingService / Test / compileIncremental fails with two errors:
computing-unit-managing-service/src/test/scala/org/apache/texera/service/resource/ComputingUnitManagingResourceSpec.scala:179:10:
value ownerGoogleAvatar is not a member of
org.apache.texera.service.resource.ComputingUnitManagingResource.DashboardWorkflowComputingUnit
computing-unit-managing-service/src/test/scala/.../ComputingUnitManagingResourceSpec.scala:285:13:
value ownerGoogleAvatar is not a member of ...
Because the amber jobs build the whole test tree, any PR whose amber jobs run after this landed fails on it, regardless of what the PR itself touches — #7631 is an example, where the only change is four tests in an unrelated module's spec.
To be precise about the blast radius rather than overstate it: PRs whose amber jobs ran before the breakage are still showing green (their runs predate it and would fail if re-run), and PRs labelled frontend-only skip the amber stack entirely. So this is not "every open PR is red right now" — it is "every amber run from here on is red until this is fixed".
Two PRs raced. #7563 renamed the field on DashboardWorkflowComputingUnit to ownerAvatar. #7580 added spec assertions written against the old name ownerGoogleAvatar. Each was green against its own base, and neither was rebased onto the other before merging, so the combination is what breaks.
The production case class on main today reads:
case class DashboardWorkflowComputingUnit(
computingUnit: WorkflowComputingUnit,
status: String,
metrics: WorkflowComputingUnitMetrics,
isOwner: Boolean,
accessPrivilege: EnumType,
ownerAvatar: String,
ownerName: String
)How to reproduce?
On a clean checkout of main:
sbt "ComputingUnitManagingService/Test/compile"
Fails with the two errors above. I verified this by stashing the fix and re-running: unpatched main exits 1 with exactly those two errors, and the patched tree compiles clean.
Version/Branch
1.3.0-incubating-SNAPSHOT (main)
Expected behavior
main compiles, and the amber jobs pass on PRs that do not touch this module.
The fix is a two-line rename of the accessor calls in the spec; the field's value is unchanged, and all 31 of that spec's tests pass afterwards, so the assertions were right about the value all along.
Worth noting for the future: this class of breakage is invisible to per-PR CI when two PRs touch different files. A required up-to-date-with-base check, or simply rebasing before merge, would have caught it.
What happened?
maindoes not compile.ComputingUnitManagingService / Test / compileIncrementalfails with two errors:Because the amber jobs build the whole test tree, any PR whose amber jobs run after this landed fails on it, regardless of what the PR itself touches — #7631 is an example, where the only change is four tests in an unrelated module's spec.
To be precise about the blast radius rather than overstate it: PRs whose amber jobs ran before the breakage are still showing green (their runs predate it and would fail if re-run), and PRs labelled frontend-only skip the amber stack entirely. So this is not "every open PR is red right now" — it is "every amber run from here on is red until this is fixed".
Two PRs raced. #7563 renamed the field on
DashboardWorkflowComputingUnittoownerAvatar. #7580 added spec assertions written against the old nameownerGoogleAvatar. Each was green against its own base, and neither was rebased onto the other before merging, so the combination is what breaks.The production case class on
maintoday reads:How to reproduce?
On a clean checkout of
main:Fails with the two errors above. I verified this by stashing the fix and re-running: unpatched
mainexits 1 with exactly those two errors, and the patched tree compiles clean.Version/Branch
1.3.0-incubating-SNAPSHOT (main)
Expected behavior
maincompiles, and the amber jobs pass on PRs that do not touch this module.The fix is a two-line rename of the accessor calls in the spec; the field's value is unchanged, and all 31 of that spec's tests pass afterwards, so the assertions were right about the value all along.
Worth noting for the future: this class of breakage is invisible to per-PR CI when two PRs touch different files. A required up-to-date-with-base check, or simply rebasing before merge, would have caught it.