Parts of this repo that are tracked in git, but generated from build steps (e.g. Cargo.lock, .pb.go files, some of the files under docs/) may be changed but not committed as part of a PR. This results in situations where you build the main branch and uncommitted changes show up even though you didn't touch anything (leaving the next person to have to include those unrelated changes in their PR.)
We should generally prevent any PR's from merging that result in uncommitted changes. Not just as a final check, but also by eagerly "causing" some uncommitted changes in more build scenarios. Particularly the protobuf schema: If a change to the rust gRPC API touches a protobuf file, it leaves the next PR into ./rest-api to deal with the code gen, when it should probably happen on the first PR instead. Combined with the clean-repo check this should prevent issues where a backlog of protobuf changes have to land on whatever PR touches rest-api next.
Parts of this repo that are tracked in git, but generated from build steps (e.g. Cargo.lock, .pb.go files, some of the files under docs/) may be changed but not committed as part of a PR. This results in situations where you build the main branch and uncommitted changes show up even though you didn't touch anything (leaving the next person to have to include those unrelated changes in their PR.)
We should generally prevent any PR's from merging that result in uncommitted changes. Not just as a final check, but also by eagerly "causing" some uncommitted changes in more build scenarios. Particularly the protobuf schema: If a change to the rust gRPC API touches a protobuf file, it leaves the next PR into ./rest-api to deal with the code gen, when it should probably happen on the first PR instead. Combined with the clean-repo check this should prevent issues where a backlog of protobuf changes have to land on whatever PR touches rest-api next.