Include aarch64-apple-darwin docs in manifest.

[ehuss]

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]

r? @Mark-Simulacrum

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

[ehuss]

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

[shepmaster]

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]

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.

[ehuss]

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]

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]

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):

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]

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.

[ehuss]

Posted #92800 with the alternative solution.

[Mark-Simulacrum]

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