ci(deploy-docs): install mdbook with install-action

[rami3l]

This PR uses the install-action to install mdbook, giving us access to the new features and/or fixes from the upstream.

We're already depending on the very same action to install taplo:

rustup/ci/actions-templates/centos-fmt-clippy-template.yaml

Lines 68 to 71 in 3fc52e9

	- name: Install taplo
	uses: taiki-e/install-action@v2
	with:
	tool: taplo-cli

[ChrisDenton]

Maybe it could also be used here:

rustup/.github/workflows/ci.yaml

Lines 1525 to 1529 in 3fc52e9

	- name: Install mdbook
	run: |
	mkdir mdbook
	curl -Lf https://github.com/rust-lang/mdBook/releases/download/v0.4.37/mdbook-v0.4.37-x86_64-unknown-linux-gnu.tar.gz | tar -xz --directory=./mdbook
	echo "`pwd`/mdbook" >> $GITHUB_PATH

And here:

rustup/ci/actions-templates/test-docs-template.yaml

Lines 15 to 19 in 3fc52e9

	- name: Install mdbook
	run: |
	mkdir mdbook
	curl -Lf https://github.com/rust-lang/mdBook/releases/download/v0.4.37/mdbook-v0.4.37-x86_64-unknown-linux-gnu.tar.gz | tar -xz --directory=./mdbook
	echo "`pwd`/mdbook" >> $GITHUB_PATH

[rami3l]

Maybe it could also be used here:

rustup/.github/workflows/ci.yaml

Lines 1525 to 1529 in 3fc52e9

	- name: Install mdbook
	run: |
	mkdir mdbook
	curl -Lf https://github.com/rust-lang/mdBook/releases/download/v0.4.37/mdbook-v0.4.37-x86_64-unknown-linux-gnu.tar.gz | tar -xz --directory=./mdbook
	echo "`pwd`/mdbook" >> $GITHUB_PATH

And here:

rustup/ci/actions-templates/test-docs-template.yaml

Lines 15 to 19 in 3fc52e9

	- name: Install mdbook
	run: |
	mkdir mdbook
	curl -Lf https://github.com/rust-lang/mdBook/releases/download/v0.4.37/mdbook-v0.4.37-x86_64-unknown-linux-gnu.tar.gz | tar -xz --directory=./mdbook
	echo "`pwd`/mdbook" >> $GITHUB_PATH

@ChrisDenton Thanks for pointing that out! I actually think these two jobs should be merged so these books can be tested on PR using the same workflow. I'll try to do that and delete this job...

[ehuss]

FWIW, I do not recommend doing this without pinning to a specific version. It is not unusual that new releases break things, and it's best to test new versions and look at how it renders before updating. (Fortunately the rustup book is pretty basic, so problems are less likely, but I still wouldn't recommend it.)

[rami3l]

FWIW, I do not recommend doing this without pinning to a specific version. It is not unusual that new releases break things, and it's best to test new versions and look at how it renders before updating. (Fortunately the rustup book is pretty basic, so problems are less likely, but I still wouldn't recommend it.)

@ehuss Thanks for the feedback! I have a question about this though:

When making this PR I thought, at least for me, it would be the best if we use the same version for local preview (I use the watch command when editing the book on my machine) and for deployment, and IIRC I've already noticed a few updates (but no breakages so far) with my local render compared to the online version...

Are we supposed to use like a one-year-old mdbook version locally, or is there a convenient way to check within our CI pipeline? Also, what kind of breakages do you have in mind?

PS: Pinning the version would simply be two extra lines in this new setup, I've done this before.

[ehuss]

Yea, it's a bit tricky to test locally with the exact same version that is used in this repo. Generally my workflow is:

1. Update locally to the latest mdbook
2. Render locally, make sure it looks ok
3. Push a PR to update to the latest version
4. (Optional) Verify the new rendering at https://rust-lang.github.io/rustup/devel/

Or if you have an automated update (like with renovatebot):

1. Renovate opens a PR to update mdbook
2. Update mdbook locally
3. Render locally, make sure it looks ok
4. Merge renovatebot's PR

So, you can generally stay on the latest version of mdbook (particularly with renovatebot), but the actual transition happens through a PR, not implicitly when new versions are published.

It's tough to say exactly what kinds of breakage might happen. Some past examples might be rust-lang/mdBook#2482, rust-lang/mdBook#2479, rust-lang/mdBook#2473, rust-lang/mdBook#2383, rust-lang/mdBook#2472, rust-lang/mdBook#1949, rust-lang/mdBook#1743, rust-lang/mdBook#1235, etc. There have also been issues with these third-party installers having problems or bugs or bad interactions or assumptions with how the releases are structured.