Git tags when packaging

[steveklabnik]

Bundler does some cool git stuff when publishing a package[1]. Conceptually, with cargo commands instead, and with error handling and rollback elided, it does this:

$ cargo build
$ git diff --exit-code == 0
$ git diff-index --quiet --cached HEAD == 0
$ git tag -a -m \"Version #{version}\" #{version_tag} 
$ git push
$ git push --tags
$ cargo publish

(version is like 1.2.3 and version_tag is like v1.2.3)

Having the tags automatically created at the same commit as was released, plus ensuring that what's on github/whatever is the same as what's on crates.io would be pretty great.

1: https://github.com/bundler/bundler/blob/master/lib/bundler/gem_helper.rb#L47-L50

[shadowmint]

I don't have much to add to this except 1) yes please, and 2) version_tag should not be prefixed with v; this is a left over from pre-2.0 of semver and no longer part of the spec.

[bluss]

packagename-VERSION may be a good tag name pattern. It works for those that have many cargo packages per repository (which is quite common: regex, quickcheck, rand, etc, many do).

I don't think cargo should push.

[sbeckeriv]

@steveklabnik how important is the push tag step? @bluss doesnt think it should push.

I have auto tagging configurable via cargo config. Its not clear to me yet on how to push tags via libgit2-rs. Also should the config live in the cargo toml so its project wide? I thought Cargo.toml was loaded in the config object but my test say otherwise.

https://github.com/rust-lang/cargo/compare/master...sbeckeriv:git-auto-tag-841?expand=1

let me know your thoughts/concerns/comments.
thanks
Becker

[Nemo157]

Just thought I'd mention that I use an inverse workflow, I tag (with PGP signature) and use that as a trigger that the CI service should publish that commit to crates.io. I feel it comes closer to ensuring reproducible builds, the exact build steps taken (modulo the setup of the CI container) are specified in the .travis.yml/.gitlab-ci.yml/... file with the code. Not sure how common this might be compared to publishing from your local dev machine though.

If this auto-tagging is configurable that would ensure this workflow still works, I'm not sure if there's any other way that this could interact better/worse with it.

[matklad]

Automatic tagging and pushing to the repo do raise some design questions.

A possibly simpler solution is to check that a tag exists before publishing. This should be done over here:

cargo/src/cargo/ops/cargo_package.rs

Line 174 in 541e990

fn check_repo_state(

That can be extended later with an opt-in ‘—tag’ flag later, and could probably be made a default after edition switch? Code for that should probably go either in that cargo_package.rs file, or here:

cargo/src/cargo/ops/registry.rs

Line 45 in 541e990

pub fn publish(ws: &Workspace, opts: &PublishOpts) -> CargoResult<()> {

I don’t feel like adding taggging by default would work without opt-in at this moment, due to backwards compatibility requirements.

[dwijnand]

This is available through https://github.com/sunng87/cargo-release.

Are we still interested in this being in cargo proper?

[steveklabnik]

I very much am! I think being "standard" here is very helpful.