aglinxinyuan opened a new issue, #7632:
URL: https://github.com/apache/texera/issues/7632
### 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, this takes down **`build /
amber` and `build / amber-integration` on every open PR**, regardless of what
that PR touches. It is currently red on unrelated PRs across the repo.
**Two PRs raced.** [#7563](https://github.com/apache/texera/pull/7563)
renamed the field on `DashboardWorkflowComputingUnit` to `ownerAvatar`.
[#7580](https://github.com/apache/texera/pull/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:
```scala
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
