Add link checking on CI

.github/workflows/deploy.yml

@@ -2,7 +2,6 @@ name: Deploy To GitHub Pages
 on:
   schedule:
     - cron: '0 22 * * *'
-  pull_request:
   push:
     branches:
       - master
@@ -16,18 +15,15 @@ jobs:
       - uses: actions/checkout@v4
       - name: Install mdbook
         run: curl -sSL https://github.com/rust-lang/mdBook/releases/download/v${MDBOOK_VERSION}/mdbook-v${MDBOOK_VERSION}-x86_64-unknown-linux-gnu.tar.gz | tar -xz
-      - name: Check blacksmith format
-        run: cargo fmt --check --manifest-path=blacksmith/Cargo.toml
       - name: Build book
         run: ./mdbook build
       - name: Upload artifact
-        if: github.ref == 'refs/heads/master'
         uses: actions/upload-pages-artifact@v3
         with:
           path: ./book
 
   deploy:
-    if: github.ref == 'refs/heads/master' && github.repository_owner == 'rust-lang'
+    if: github.repository_owner == 'rust-lang'
     needs: build
 
     permissions:

.github/workflows/test.yml

@@ -0,0 +1,20 @@
+name: Test
+on:
+  pull_request:
+
+jobs:
+  test:
+    name: CI
+    runs-on: ubuntu-latest
+    env:
+      MDBOOK_VERSION: 0.4.51
+    steps:
+      - uses: actions/checkout@v4
+      - name: Install mdbook
+        run: curl -sSL https://github.com/rust-lang/mdBook/releases/download/v${MDBOOK_VERSION}/mdbook-v${MDBOOK_VERSION}-x86_64-unknown-linux-gnu.tar.gz | tar -xz
+      - name: Install mdbook-linkcheck
+        run: cargo install [email protected] --locked
+      - name: Check blacksmith format
+        run: cargo fmt --check --manifest-path=blacksmith/Cargo.toml
+      - name: Build book
+        run: ./mdbook build

README.md

@@ -24,6 +24,12 @@ you to easily see and update changes you make.
 mdbook serve
 ```
 
+## Link checking
+
+On CI, we automatically check if all intra-doc links in the Forge Markdown files are valid. If you would like to
+perform this check locally, install `mdbook-linkcheck` using `cargo install [email protected] --locked` and then
+simply run `mdbook build` or `mdbook serve`.
+
 ## JavaScript
 
 Forge uses JavaScript to display dates for releases and "no tools breakage

book.toml

@@ -61,3 +61,7 @@ smart-punctuation = true
 "platforms/zulip/triagebot.html" = "/triagebot/index.html"
 "core/blogs.html" = "/platforms/blogs.html"
 "core/index.html" = "/governance/council.html"
+
+[output.linkcheck]
+follow-web-links = false
+optional = true

src/compiler/cross-team-collaboration.md

@@ -10,7 +10,7 @@ label to a issue (you can include `@rustbot label +I-compiler-nominated` in
 your comment to do this).
 
 Once nominated, the issue will be discussed in a upcoming [triage
-meeting](./triage-meeting.html). The compiler team doesn't always get through
+meeting](./meetings.md#triage-meeting). The compiler team doesn't always get through
 all nominated issues each week, so it can take more than one meeting for your
 issue to be discussed.
 
@@ -60,7 +60,7 @@ Add the `I-compiler-nominated` label to a issue (you can use `@rustbot label
 +I-compiler-nominated` to do this).
 
 Once nominated, the issue will be discussed in a upcoming [triage
-meeting](./triage-meeting.html). The compiler team doesn't always get through
+meeting](./meetings.md#triage-meeting). The compiler team doesn't always get through
 all nominated issues each week, so it can take more than one meeting for your
 issue to be discussed. In the compiler team's discussion, the issue may..
 

src/compiler/membership.md

@@ -5,7 +5,7 @@ This team discusses membership in the compiler team. There are currently two lev
 * maintainers: members who have committed themselves to invest in the quality of the compiler and
   health of the compiler team
 
-[infrastructure]: ../infra/index.html
+[infrastructure]: ../infra/README.md
 
 ## The path to membership
 People who are looking to contribute to the compiler typically start in one of two ways. They may 
@@ -52,9 +52,8 @@ Being promoted to member implies a number of privileges:
 It also implies some obligations (in some cases, optional obligations):
 
 - Members will be asked if they wish to be added to the reviewer rotation.
-- Members may take part in various other [maintainer activities] to help the team. 
-- Members are held to a higher standard than ordinary folk when it comes to the [Code of
-  Conduct][CoC].
+- Members may take part in various other maintainer activities to help the team. 
+- Members are held to a higher standard than ordinary folk when it comes to the [Code of Conduct][CoC].
 
 [listed]: https://www.rust-lang.org/governance/teams/compiler
 
@@ -82,7 +81,7 @@ After being a compiler team member for a year, members can request or be asked t
 actively helping to shape the direction of the team or some part of the compiler (or multiple
 parts).
 
-- Compiler team maintainers are expected to participate in at least one [maintenance activities].
+- Compiler team maintainers are expected to participate in at least one maintenance activities.
 - Compiler team maintainers are identified with the "Maintainer" role on the rust-lang website.
 
 ## How promotion decisions are made

src/compiler/prioritization.md

@@ -217,5 +217,5 @@ After the meeting, there are a few closing tasks:
 [forge_announce]: https://github.com/rust-lang/rust-forge/issues?q=label%3Afinished-final-comment-period+label%3Ato-announce
 [fcps]: https://github.com/rust-lang/compiler-team/issues?q=label%3Amajor-change+label%3Ato-announce
 [mcps]: https://github.com/rust-lang/compiler-team/issues?q=label%3Amajor-change+label%3Ato-announce
-[relese_backports]: ../release/backporting.md
+[release_backports]: ../release/backporting.md
 [compiler_nominated]: https://github.com/rust-lang/rust/issues?q=is%3Aopen+label%3AI-compiler-nominated+label%3AT-compiler

src/compiler/proposals-and-stabilization.md

@@ -64,6 +64,7 @@ the nature of the proposal, described below.
 
 [rust-lang/compiler-team]: https://github.com/rust-lang/compiler-team
 [design meeting proposal]: ./meetings.md#steeringplanning-meeting
+[major change template]: https://github.com/rust-lang/compiler-team/issues/new?template=major_change.md
 
 #### What kinds of comments should go on a MCP in the compiler-team repo?
 Please direct technical conversation to the Zulip stream.
@@ -360,7 +361,7 @@ See [*Backports*](./backports.md).
 
 ### Adding ecosystem/integration test jobs/components to rust-lang/rust CI
 
-See [*Adding ecosystem/integration test jobs/components to rust-lang/rust CI*](./proposals-and-stabilization/custom-test-jobs.md).
+See [*Adding ecosystem/integration test jobs/components to rust-lang/rust CI*](./proposals-and-stabilization/ecosystem-integration-tests.md).
 
 
 [stabilization_guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html

src/compiler/reviews.md

@@ -497,3 +497,4 @@ team](https://www.rust-lang.org/governance/teams/moderation) to step in.
 
 [coc]: https://www.rust-lang.org/policies/code-of-conduct
 [rollup]: ../release/rollups.md
+[MCP]: ./proposals-and-stabilization.md#how-do-i-submit-an-mcp

src/compiler/third-party-out-of-tree.md

@@ -10,7 +10,7 @@ in `rust-lang`) and that the experience is uniform across `rust-lang/rust` and t
 ### When should parts of the compiler be extracted into an out-of-tree crate?
 This is left to the discretion of compiler team members but should be discussed with the rest of
 the team, either through raising the question at the weekly triage meeting or asynchronously using
-[an approval decision](./proposals-and-stabilizations.md). If the crate is a product of a working
+[an approval decision](./proposals-and-stabilization.md). If the crate is a product of a working
 group, there should already be agreement within the working group that an out-of-tree crate is
 suitable.
 
@@ -123,9 +123,9 @@ In summary, the process for establishing an out-of-tree crate is as follows:
 
        > This crate is developed and maintained by the [Rust compiler team](https://github.com/rust-lang/compiler-team/tree/master/procedures) for use within
        > `rustc`, in particular, it is the responsibility of the
-       > [`.template`](../../working-groups/template) working group. This crate [will have regular
-       > breaking changes and provides no stability guarantees|is intended to remain stable and have
-       > limited breaking changes].
+       > [`.template`](./working-areas.md) working area. This crate will have regular
+       > breaking changes and provides no stability guarantees | is intended to remain stable and have
+       > limited breaking changes.
     1. Include the [LICENSE-APACHE][apache] and [LICENSE-MIT][mit] files from `rust-lang/rust`.
     1. Include or link the [CODE_OF_CONDUCT][coc] file from `rust-lang/rust`.
     1. Create a relevant `.gitignore` ([here's a sane default][gitignore]).
@@ -137,7 +137,7 @@ In summary, the process for establishing an out-of-tree crate is as follows:
 [gitignore]: https://gitignore.io/api/vim,rust,emacs,clion,visualstudio,visualstudiocode
 [triagebot]: https://github.com/rust-lang/rust/blob/master/triagebot.toml
 [apache]: https://github.com/rust-lang/rust/blob/master/LICENSE-APACHE
-[coc]: ../../about/code_of_conduct
+[coc]: https://www.rust-lang.org/policies/code-of-conduct
 [mit]: https://github.com/rust-lang/rust/blob/master/LICENSE-MIT
 
 ## Third-party crates

src/compiler/working-areas.md

@@ -2,16 +2,16 @@
 
 Much of the ongoing work and initiatives from the compiler team are performed by groups of people interested in specific areas of work. These groups are a great way for new contributors to get involved as they provide a stream of tasks focused around one area and have designated channels for help and advice. Here is a list of areas where work is being carried on:
 
-Name                              | Short Description                                                                                  | Code | Zulip Stream
-----                              | -----------------                                                                                  | ---------- | ------------
-Async-await Implementation        | Implementing async-await                                                                           | [Link][async-await_code] | [#wg-async][async-await_stream]
-Diagnostics                       | Use crates.io crates for diagnostics rendering and make emitting diagnostics nicer.                | [rustc_errors], [rustc_lint], [annotate-snippets] | [#t-compiler/diagnostics][diagnostics_stream]
-LLVM                              | Working with LLVM upstream to represent Rust in its development                                    | [rustc], [LLVM][llvm_code] | [#t-compiler/llvm][llvm_stream]
-MIR Optimizations                 | Write MIR optimizations and refactor the MIR to be more optimizable.                               | [MIR transform](mir_transform_code) | [#t-compiler/mir-opts][mir-opts-stream]
-Parallel-rustc                    | Making parallel compilation the default for rustc                                                  | [rustc] | [#t-compiler/parallel-rustc][parallel-rustc_stream]
+Name                              | Short Description                                                                                  | Code                                                                        | Zulip Stream
+----                              | -----------------                                                                                  |-----------------------------------------------------------------------------| ------------
+Async-await Implementation        | Implementing async-await                                                                           | [Link][async-await_code]                                                    | [#wg-async][async-await_stream]
+Diagnostics                       | Use crates.io crates for diagnostics rendering and make emitting diagnostics nicer.                | [rustc_errors], [rustc_lint], [annotate-snippets]                           | [#t-compiler/diagnostics][diagnostics_stream]
+LLVM                              | Working with LLVM upstream to represent Rust in its development                                    | [rustc], [LLVM][llvm_code]                                                  | [#t-compiler/llvm][llvm_stream]
+MIR Optimizations                 | Write MIR optimizations and refactor the MIR to be more optimizable.                               | [MIR transform][mir_transform_code]                                         | [#t-compiler/mir-opts][mir-opts-stream]
+Parallel-rustc                    | Making parallel compilation the default for rustc                                                  | [rustc]                                                                     | [#t-compiler/parallel-rustc][parallel-rustc_stream]
 Polonius                          | Exploring the integration of the "NLL 2.0"-like ["Polonius analysis"][Polonius] into rustc         | [borrow check][borrowck], [rust-lang/polonius][P], [rust-lang/datafrog][DF] |  [#t-types/polonius][polonius_stream]
-RLS 2.0                           | Experimenting with a new compiler architecture tailored for IDEs                                   | [rust-analyzer][ra-repo] | [#t-compiler/rust-analyzer][rls20_stream]
-Rustc Dev Guide                   | Make the compiler easier to learn by ensuring that rustc-dev-guide is "complete"                   | [rustc], [rustc-dev-guide][rustc-dev-guide-repo] | [#t-compiler/rustc-dev-guide][rustc-dev-guide_stream]
+RLS 2.0                           | Experimenting with a new compiler architecture tailored for IDEs                                   | [rust-analyzer][ra-repo]                                                    | [#t-compiler/rust-analyzer][rls20_stream]
+Rustc Dev Guide                   | Make the compiler easier to learn by ensuring that rustc-dev-guide is "complete"                   | [rustc], [rustc-dev-guide][rustc-dev-guide-repo]                            | [#t-compiler/rustc-dev-guide][rustc-dev-guide_stream]
 
 For historical record here's a list of Working Groups that are not active anymore (either because they reached their goals or because work stalled):
 

src/infra/service-infrastructure.md

@@ -49,7 +49,7 @@ Documentation on rfcbot commands can be found
 [rustbot](https://github.com/rust-lang/triagebot) is a bot ([bot user
 account](https://github.com/rustbot)) to assist with managing issues and PRs
 to allow users to label and assign without GitHub permissions. See
-[triagebot](../triagebot/index.html) for more information.
+[triagebot](../triagebot) for more information.
 
 ## DXR
 

src/infra/toolstate.md

@@ -108,4 +108,4 @@ To add a new tool to be tracked, the following steps must be taken:
 [subup]: https://github.com/ehuss/subup
 [toolstate]: https://rust-lang-nursery.github.io/rust-toolstate/
 [toolstate repository]: https://github.com/rust-lang-nursery/rust-toolstate/
-[forge]: ../index.html
+[forge]: ../README.md

src/libs/README.md

@@ -9,4 +9,4 @@ It has details on current project groups, upcoming meetings, and the status of t
 
 The Libs team hangs out primarily in [the rust-lang Zulip](https://rust-lang.zulipchat.com/) these days in the `#t-libs` stream.
 
-You can also find out more details about [Zulip and how the Rust community uses it](../../platforms/zulip.html).
+You can also find out more details about [Zulip and how the Rust community uses it](../platforms/zulip.md).

src/policies/crate-ownership.md

@@ -85,11 +85,11 @@ These should by and large not be considered to be "team managed" crates; this ca
 
 ## Transitions and new crates
 
-Teams should feel free to create new crates in any of these categories; however "Intentional Artifact" crates must be accompanied with an RFC. As we move towards having team charters, this can transition to being a charter change (which may require an RFC or use its own process). Teams should notify <[email protected]> when they've created such crates so that the Leadership Council may track these crates and ensure this policy is applied.
+Teams should feel free to create new crates in any of these categories; however "Intentional Artifact" crates must be accompanied with an RFC. As we move towards having team charters, this can transition to being a charter change (which may require an RFC or use its own process). Teams should notify `[email protected]` when they've created such crates so that the Leadership Council may track these crates and ensure this policy is applied.
 
 From time to time a team's plan for a crate may change: experiments may conclude, crates may need to be deprecated, or the team may decide to release something for wider usage.
 
-In general, teams should notify <[email protected]> when such a transition is being made.
+In general, teams should notify `[email protected]` when such a transition is being made.
 
 Any transition _away_ from "Intentional Artifact" requires an RFC.