Description
Now that the builds in rust-lang/rust are documenting rustfmt as well (rust-lang/rust#87119), we should update our build process to ensure we're not introducing anything that will trigger warnings since such warnings will be hard errors in rust-lang/rust, and they won't show until bors tests the changes (refs rust-lang/rust#90087)
Other than this check needing to be added as part of a GitHub Actions workflow and executed on PRs, it doesn't really matter to me which file the job is defined within nor how it's implemented.
We won't be able to run it exactly the same in our CI as it's executed in rust-lang/rust CI, but should be able to get sufficiently close. The specific args/flags utilized in the compiler build can be derived from here
Note that the rustdoc flags can be provided as an environment variable (e.g. RUSTDOCFLAGS="--document-private items..."), and be sure to include
-D warningsto match the behavior in the compiler builds. Other than that the command should be something simple along the lines of
cargo doc -p rustfmt-nightly -p rustfmt-config_proc_macro` along with the rest of the other flags/args
Activity
ytmimi commentedon Oct 22, 2021
Would adding another job to
.github/workflows/linux.yaml
work, or would you prefer a new workflow file be created? something like this:calebcartwright commentedon Oct 23, 2021
That looks good to me, though we don't need to worry about a matrix-based job for the doc check.
Will defer to you on which file, I don't really have a preference. One of the motivating factors for separating out the linux/windows/mac jobs into separate workflows is that it makes status reporting and status badges more feasible for the platforms individually. Beyond that I think the same file vs. new file for any subsequent jobs will just boil down to whatever we think will work best. I guess we do already have the integration function in a separate file/workflow, so maybe this warrants a separate workflow/file for pattern consistency?
ytmimi commentedon Oct 23, 2021
I added the matrix because I wanted to be consistent with the way the linux test jobs were setup, but good to note!
I like the idea of placing the Doc CI job into its own file. It also feels more consistent to me. I'll open a PR soon!