Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include aarch64-apple-darwin docs in manifest. #92622

Closed
wants to merge 1 commit into from

Conversation

ehuss
Copy link
Contributor

@ehuss ehuss commented Jan 6, 2022

The docs are being built on the dist-aarch64-apple builder, but they are not included in the manifest so people can't download them with rustup. This adds them to the manifest.

@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 6, 2022
@ehuss
Copy link
Contributor Author

ehuss commented Jan 6, 2022

cc @shepmaster Was there a reason this wasn't included?

@shepmaster
Copy link
Member

Officially, aarch64-apple-darwin is tier 2 and:

Tier 2 targets currently do not build the rust-docs component

My personal opinion is that we should treat this platform as effectively tier 1. Once we get native CI runners, the plan is to make it tier 1 as far as I know.

If we have a best-effort doc component without guarantees of availability, I think it’d be nice.

/cc @rust-lang/infra

@Mark-Simulacrum
Copy link
Member

Hm, well, it definitely seems like building and then not shipping the docs is not great. In that sense this seems OK.

That said, I will note that the dist-aarch64-apple builder is -- and has been -- our longest builder for quite a while, so I'd at least tentatively suggest that maybe we should stop building docs instead of shipping them, or perhaps find a way to do so on a separate (non-macOS-based?) builder. IOW, I'm worried that shipping these docs will create pressure on us to not stop doing so in the future, and in the absence of this PR so to speak, I would've probably suggested we stop building the docs to save time.

image

@ehuss
Copy link
Contributor Author

ehuss commented Jan 6, 2022

I'd also be fine with disabling docs, it should save a little bit of time (I can't remember, but I seem to recall it being on the order of 5 minutes). Where did you get that fancy graph? It's a bit concerning that there has been such a large, steady increase in time over the past few months.

Also, would another option be to fix #69525 by just pointing all missing docs targets to x86_64-unknown-linux-gnu in the manifest? I'm not sure if rustup will work with that, but i seem to recall that it will strip the first directory component, so I think it should. I understand that some people would prefer native docs due to rare platform differences, but it should be the same as visiting https://doc.rust-lang.org/.

@shepmaster
Copy link
Member

pointing all missing docs targets to x86_64-unknown-linux-gnu

for this example, pointing to x86_64-apple-darwin would be better, if that’s possible.

FWIW I think that these docs must have been accidentally enabled at some point, as I distinctly remember trying to have them originally built and then we discussed the tier 2 issues.

@Mark-Simulacrum
Copy link
Member

I just pushed the code I use to create that graph - https://github.com/Mark-Simulacrum/rustc-ci-timing. I believe the increase is largely out of our hands -- as far as I can tell, it's not due to rustc or our CI getting inherently slower, but rather likely something external (e.g., the machines we're running on). You can see for example that the dist-x86_64-linux builder did not significantly change over the same time period (other than the one jump for LLVM PGO; not sure I recall the reason for the second jump):

image

I agree that if we can do #69525 as an interim solution for the non-tier-1 targets at least, that seems like a good idea -- even if that means e.g. custom code on the promote-release side or elsewhere that re-bundles the x86_64-unknown-linux-gnu docs into a correctly prefixed archive, though obviously that'd be nice to avoid.

@ehuss
Copy link
Contributor Author

ehuss commented Jan 6, 2022

Interesting! Thanks for putting that together.

I'll circle back here when I get a chance to look at the feasibility to include docs from other builders in the manifest. I'm not sure when that will be, but I'll try to not let it sit for too long.

@shepmaster To disable docs, this line needs to include --disable-docs. I did a quick scan, and I also noticed that aarch64-pc-windows-msvc and x86_64-unknown-linux-musl are also building docs that are not included in the manifest.

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 10, 2022
@ehuss
Copy link
Contributor Author

ehuss commented Jan 12, 2022

Posted #92800 with the alternative solution.

@Mark-Simulacrum
Copy link
Member

Going to go ahead and close this, as #92800 is what I'd prefer at this point. (We can always reopen of course).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants