Would you be open to adding other tools to the image?
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
No files or tests are named. Review the current image definitions and verify how nightly tool installation and publishing work; then determine whether cargo-deny, cargo-hack, and cargo-llvm-cov fit a documented inclusion policy, version strategy, and maintenance cadence.
Written by the indexing model from the issue text.
Description
Personally, I believe that running cargo install as part of a pipeline is an antipattern - it makes the jobs much longer, for little to no benefit.
That's why I maintain my own image on top of rust which I update as needed.
It would be amazing if popular and powerful crates were added to upstream images. At the moment, I can name three that I would like to see included:
cargo-deny- for auditing dependencies and lintingCargo.tomlcargo-hack- for easy testing of featurescargo-llvm-cov- for coverage
This would be a huge step, and I can see some downsides to this:
- need for regular builds and publishing of at least latest stable version, to keep tools updated (seems to be implemented for nightly?)
- increased burden on maintainers in filtering feature requests what to include and what not to include
- one time: need to set policy on which tools are fine, and which are not
I'm posting this as a general proposal, because from what I can see, the current images only really install the base toolchain and nothing more.
Regarding the policy: one thing I'd explicitly deny is duplicates of existing functionality. So, if cargo-deny makes it, cargo-audit would not get added later on because it adds nothing new. Similarly, sccache (#143) doesn't seem to make sense - most CI runners have their own caching and I'm not sure what it would add on top of that. But the specifics are for later, when you decide if you even want to open up to extra tools.
- Dominant language
- Dockerfile
- Stars
- 537
- Forks
- 111
- Avg merge
- 1d 39m
- Merged PRs (30d)
- 4
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rust-lang/docker-rust
-
Difficulty 1/5 Under an hour Newbie friendliness 68/100
rust-lang/docker-rust#159 · 1 reaction ·
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
rust-lang/docker-rust#278 ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
rust-lang/docker-rust#264 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 52/100
rust-lang/docker-rust#263 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
rust-lang/docker-rust#248 · 1 comment ·
All issues in rust-lang/docker-rust
Similar issues
-
ready-for-triage
Difficulty 1/5 Under an hour Newbie friendliness 88/100
konflux-ci/konflux-ui#1596 · 1 comment ·
Maintainers usually reply within 1 day
-
[Bug]: core doesn't build standalone on dev since a17068054 (go-mp3 require dropped, go.sum pruned)Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
priority: P3 type: devops
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
jiegui2025/hwspec#57 ·
Maintainers usually reply within 1 day
-
area: release bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
TMHSDigital/subenum#102 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day