I think it will be important for build-std to be tested in the rust-lang/rust CI. However, since the cargo side is so tightly coupled with the structure of the std source tree, that will make things difficult (particularly if a change needs to happen in both repos).
Some rough thoughts and ideas:
We could use something like rust-toolstate to track failures in build-std. I'm not terribly enthusiastic about that, since rust-toolstate in general was an unpleasant system. Also, a breaking change in rust-lang/rust would break cargo's CI. Cargo's CI could pin a nightly, but then cargo would need to very frequently update that.
We could use something like git subtrees. I don't particularly feel comfortable trying to track changes that happen on the rust-lang/rust side, and I don't have confidence that everyone with review rights will avoid making changes to src/tools/cargo without conferring with the team. It also puts a larger burden on our update process, and release processes (though it is unclear how much).
Reduce how tightly coupled cargo is with how std is built. This would be good in general, but I am skeptical that we can completely remove all coupling.
We'll need to decide which targets get tested and how.
Somewhat related to this is how much CI time can be afforded. I think building std takes about a minute, but building cargo's testsuite to run the tests could take longer since that would need building all of cargo (as a test). We might need some separate test suite that is independent of cargo.
Subtrees seem to be the most feasible solution, but I'm not particularly excited about them.
I think it will be important for build-std to be tested in the rust-lang/rust CI. However, since the cargo side is so tightly coupled with the structure of the std source tree, that will make things difficult (particularly if a change needs to happen in both repos).
Some rough thoughts and ideas:
Subtrees seem to be the most feasible solution, but I'm not particularly excited about them.