Record git hash of source tree in package #5629
Comments
matklad
added
the
C-feature-request
|
Sorry for the slow reply, the decisive people that have final say on these things are on vacation or otherwise unavailable. My impression is that they will be back soon. FWIIW, I like the suggestion. |
|
This also sounds like a great idea to me! We could pretty easily have something like |
|
Good to hear, thanks! I'm happy to help, ideally with some pointers, if you feel its easy enough or the "help-wanted" label is appropriate. |
|
Oh assistance in implementing this would be most welcome! This feature would go somewhere around here most likely I believe |
For future expansion's sake maybe name it |
Generate .cargo_vcs_info.json and include in `cargo package` (take 2) Implements #5629 and supersedes #5786, with the following improvements: * With an upstream git2-rs fix (tracked #5823, validated and min version update in: #5858), no longer requires windows/unix split tests. * Per review in #5786, drops file system output and locks for .cargo_vcs_info.json. * Now uses serde `json!` macro for json production with appropriate escaping. * Now includes a test of the output json format. Possible followup: * Per discussion in #5786, we could improve reliability of both the VCS dirty check and the git head sha1 recording by preferring (and/or warning otherwise) the local repository bytes of each source file, at the same head commit. This makes the process more appropriately like an atomic snapshot, with no sentry file or other locking required. However given my lack of a window's license and dev setup, as exhibited by troubles of #5823, this feel intuitively like too much to attempt to change in one iteration here. I accept the "best effort" concept of this feature as suggested in #5786, and think it acceptable progress if merged in this form. @alexcrichton r? @joshtriplett cc
|
Fixed in #5886 |
Cargo has gained a feature where it records the package-time VCS commit: * rust-lang/cargo#5886 * rust-lang/cargo#5629
The
cargo packagestep now requires that the source tree is clean (has no uncommitted changes).The automating of
git tagon release is proposed in #841 with some WIP.As (previously) proposed, recording the git hash is compatible with these and would be immediately useful. In a comment on #2640 @alexcrichton suggests that "we could record the SHA" after ensuring a commit is published, etc. But I don't think it is necessary to ensure that a commit is pushed to its canonical repo in order for the SHA hash to be useful.
For example, there's a crate with 30K downloads where the author doesn't bother with a change log or even release tags. With best efforts, manually created release tags are sometimes forgotten or delayed, raising the question of what was the commit that was released. Even with #841 in place, a recorded hash would be reassuring. Tags can be changed. It may not be practical to automatically push tags, given workflow differences.
Utility:
If a SHA hash can be extracted (or seen on crates.io) and it matches a signed git tag in the canonical repository, that is very reassuring. A+!
Otherwise if it disagrees with (any) tag, but matches a plausible commit in the canonical tree, then that is at least somewhat reassuring, and possibly worth followup with the author.
If it doesn't match any commit in the canonical repo, that's a definite warning flag, and I have a starting point to followup with the author.
Eventually something like crates.io (and/or deps.rs) could actually automate the comparison of the SHA hash with a commit/tag in the canonical repo, warning if there is any disparity. This woundn't obviate the need for other forms of security, like rust-lang/crates.io#75, but it would be complementary.
The text was updated successfully, but these errors were encountered: