Check-only Clippy & Fmt for CI/CD

tools and infrastructure
1

The official rust images confusingly have these components linked in $CARGO_HOME/bin, but nothing behind in $RUSTUP_HOME. I laud the desire to keep the images minimal. And also the checking functionalities would seem a must-have for CI/CD.

  1. I don’t know if these tools’ file-modifying features can be turned off. For this scenario that would make sence. And it would make the binaries smaller.

  2. You might think about having a cargo-slim / std variant in the corresponding OS-slim / std images. For symmetry’s sake the same might then need to be done for Alpine.

  3. We have supply-chain safe channels for hub.docker.com and crates.io, but not for rustup. For the latter it is not even clear what would need to be configured on Artifactory. The idea of setting up an https_proxy or even socks, received no love from our admins.

  4. As a workaround we’d be happy enough, if it were just possible to cargo install clippy rustfmt. Somehow that doesn’t seem possible at all. (Or extremely outdated…)

2

The docker images don't have rustup at all, so there is no $RUSTUP_HOME.

You can pass --check to rustfmt or not pass --fix to clippy. Neither would get smaller from disabling the file modification functionality. For rustfmt it would only skip the final std::fs::write as the checking is done after fully formatting it in memory. And for clippy I suspect it reuses the existing cargo fix of cargo.

I doubt this would help much. Rustc + the C toolchain is way bigger than the base OS. And basically everything other than rustfmt needs a C toolchain to build build script and proc macros.

Rustup has the RUSTUP_DIST_SERVER env var to determine the server to download from. You can download from https://static.rust-lang.org and point rustup to the server you downloaded it to.

Neither clippy nor rustfmt is published to crates.io. They are tied to a single rustc version as they use internal compiler api's that are not available on stable, hence why they are distributed as components for the rust toolchain.

2 Likes
3

I mean these rust images, which are labelled as official. Running a Shell via podman on rust:1.95.0-slim, it has obviously been installed by rustup:

# echo $RUSTUP_HOME $CARGO_HOME
/usr/local/rustup /usr/local/cargo
# ls -l $RUSTUP_HOME/toolchains/1.95.0-aarch64-unknown-linux-gnu/bin $CARGO_HOME/bin
/usr/local/cargo/bin:
total 19048
lrwxrwxrwx 1 root root        6 Apr 16 23:59 cargo -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 cargo-clippy -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 cargo-fmt -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 cargo-miri -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 clippy-driver -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 rls -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 rust-analyzer -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 rust-gdb -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 rust-gdbgui -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 rust-lldb -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 rustc -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 rustdoc -> rustup
lrwxrwxrwx 1 root root        6 Apr 16 23:59 rustfmt -> rustup
-rwxrwxrwx 1 root root 19502880 Apr 16 23:59 rustup

/usr/local/rustup/toolchains/1.95.0-aarch64-unknown-linux-gnu/bin:
total 58296
-rwxrwxrwx 1 root root 40615904 Apr 16 23:59 cargo
-rwxrwxrwx 1 root root      980 Apr 16 23:59 rust-gdb
-rwxrwxrwx 1 root root     2160 Apr 16 23:59 rust-gdbgui
-rwxrwxrwx 1 root root     1060 Apr 16 23:59 rust-lldb
-rwxrwxrwx 1 root root  2333568 Apr 16 23:59 rustc
-rwxrwxrwx 1 root root 16728448 Apr 16 23:59 rustdoc

For the rest, thanks for your clarifications!

1 Like
4

Indeed. My bad. docker-rust/Dockerfile-debian.template at 78eddf7aaa7cb9dd12d6e95605301d8a9f74290e · rust-lang/docker-rust · GitHub

1 Like