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.

[epage]

We discussed this in the team meeting today in favor of closing this.

While we understand the desire for releases to follow best-practices, like tagging, we felt this shouldn't belong in a more purpose-focused command like cargo publish. An alternative would be for a new built-in command that covers the release process, but with varying workflows (tag triggered releases, bors workflows, changelog updating, etc), this seems like it'd be better for us to leave to the community to be developing in third-party tools.