Exclude README.md from cargo change tracking #995
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In packages using cargo-readme, README.md files are touched by build.rs, which
triggers cargo's change tracking in the next build. This means cargo is
rebuilding the package every time.
This change adds README.md to the exclude list in Cargo.toml files so that
cargo doesn't think a README change requires a rebuild. Most of our packages
use cargo-readme to generate README.md, and for packages that don't, this still
isn't harmful; manual updates to README.md don't need a Rust build. (Special
cases can just remove this exclude line.)
The downside is that accidental changes to README.md, like removing it, won't
be automatically corrected with a rebuild if you haven't touched anything else.
This should be rare, and will correct itself upon any other change. (And a
developer is unlikely to commit such an accidental change.)
Thanks to @bcressey for finding this!
Testing done:
Without this, I observed crates with cargo-readme (and their local dependencies) rebuilding every
cargo build
.With this,
cargo build
finishes immediately in successive attempts.Also, at least for me and Zac,
cargo make
was rebuilding theos
package every time, which is not a quick one. With this change, thebuild-packages
step finishes very quickly and the only work we're redoing is image builds.Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.