You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would running cargo metadata be enough as a smoke test?
Yes, at least for these two recent issues that would have been enough.
I was about to open an issue asking @rust-lang/infra for what is the best way to test this. :)
I wonder if it makes sense to have something likecitool, but post-dist build, which actually exercises the final dist artifacts (literally unpacking from a dist archive, for instance) that the users would actually receive.
(Testing rustc-src dist component may be one of its jobs)
I mean, in the ideal world we should do all (or almost all) of our testing on the dist artifacts, but that woud be too costly CI wise at the moment (apart from other problems).
The rustc-src component should IMO have its own separate job, rather than being a part of the x64 dist builder. Then we could add specific smoke tests to it.
Wait, wouldn't we still have to produce the rustc-src dist component in the first place? Or as in a fast custom dist component (say at stage 1 or sth)?
Yeah I meant to create a new CI job that would create the dist rustc-src component. It doesn't require almost anything and should be very fast to build.
Where in CI (i.e. which runner and where in the logic that runs CI) would even be the right place for such tests?
EDIT: Ah seems this was already discussed a bit and the suggestion was to add a new runner. Is the idea that it would duplicate the work of building the artifact but then instead of uploading it somewhere it would test it? Wouldn't it be easier to do this somewhere where the artifact is already being built anyway?
The runners where we build dist components don't do almost any testing today, so I don't think that it would be necessarily easier.
We can add a new bootstrap step (e.g. similar to x test distcheck, which already tries to build rustc from the plain source tarball archive) for this. The important part is determining what we actually want to test; we most likely won't be able to replicate exactly what downstream does, so we should instead write down some rules, like "it has to be possible to extract rustc-dev and then build a simple rustc_private component from it", or something like that.
Activity
jieyouxu commentedon Mar 18, 2025
(Related to #136822)
jieyouxu commentedon Mar 18, 2025
I also don't think this is really compiletest, it probably needs to be its own test suite post-dist doing some basic checks.
RalfJung commentedon Mar 18, 2025
Yes, at least for these two recent issues that would have been enough.
I was about to open an issue asking @rust-lang/infra for what is the best way to test this. :)
RalfJung commentedon Mar 18, 2025
Maybe let's make this issue here specific for
rustc-src, and use the other one to track more potential tests.[-]Add a way to test dist components[/-][+]test `rustc-src` dist component on CI[/+]2 remaining items
jieyouxu commentedon Mar 18, 2025
I wonder if it makes sense to have something like
citool, but post-dist build, which actually exercises the final dist artifacts (literally unpacking from a dist archive, for instance) that the users would actually receive.(Testing
rustc-srcdist component may be one of its jobs)Kobzol commentedon Mar 18, 2025
I mean, in the ideal world we should do all (or almost all) of our testing on the dist artifacts, but that woud be too costly CI wise at the moment (apart from other problems).
The rustc-src component should IMO have its own separate job, rather than being a part of the x64 dist builder. Then we could add specific smoke tests to it.
jieyouxu commentedon Mar 18, 2025
Wait, wouldn't we still have to produce the
rustc-srcdist component in the first place? Or as in a fast custom dist component (say at stage 1 or sth)?Kobzol commentedon Mar 18, 2025
Yeah I meant to create a new CI job that would create the dist rustc-src component. It doesn't require almost anything and should be very fast to build.
Kobzol commentedon Mar 18, 2025
Just a note that this problem occurred in the
rustc-devcomponent, notrustc-src.RalfJung commentedon Mar 18, 2025
Ah, the folder is called
rustc-srcbut the componentrustc-dev.[-]test `rustc-src` dist component on CI[/-][+]test `rustc-dev` dist component on CI[/+]RalfJung commentedon Sep 2, 2025
This would have caught the recent regression (rust-lang/rust-analyzer#20584).
Where in CI (i.e. which runner and where in the logic that runs CI) would even be the right place for such tests?
EDIT: Ah seems this was already discussed a bit and the suggestion was to add a new runner. Is the idea that it would duplicate the work of building the artifact but then instead of uploading it somewhere it would test it? Wouldn't it be easier to do this somewhere where the artifact is already being built anyway?
Kobzol commentedon Sep 2, 2025
The runners where we build dist components don't do almost any testing today, so I don't think that it would be necessarily easier.
We can add a new bootstrap step (e.g. similar to
x test distcheck, which already tries to build rustc from the plain source tarball archive) for this. The important part is determining what we actually want to test; we most likely won't be able to replicate exactly what downstream does, so we should instead write down some rules, like "it has to be possible to extract rustc-dev and then build a simple rustc_private component from it", or something like that.RalfJung commentedon Sep 2, 2025
Just running
cargo metadata --manifest-path .../compiler/rustc/Cargo.tomlwould already have caught all the regressions mentioned here, I think.In particular, building Miri wasn't even broken (since it uses the rlibs and does not care about the sources). Only the RA/vscode integration broke.
Kobzol commentedon Sep 2, 2025
Let's try: #146124
Rollup merge of rust-lang#146124 - Kobzol:distcheck-ext, r=jieyouxu
Rollup merge of rust-lang#146124 - Kobzol:distcheck-ext, r=jieyouxu
Unrolled build for #146124