crate-ci / cargo-release Goto Github PK

Probably related to TeXitoi/structopt#125

~$ cargo -V
cargo 1.27.0 (1e95190e5 2018-05-27)
~$ rustc -V
rustc 1.27.0 (3eda71b00 2018-06-19)

cargo install cargo-release
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading cargo-release v0.10.5                                              
  Installing cargo-release v0.10.5                                              
 Downloading maplit v0.1.6
 Downloading toml v0.3.2                                                        
 Downloading dirs v1.0.4                                                        
 Downloading serde v0.9.15                                                      
   Compiling proc-macro2 v0.4.24                                                
   Compiling version_check v0.1.5
   Compiling unicode-xid v0.1.0
   Compiling num-traits v0.2.6
   Compiling num-integer v0.1.39
   Compiling cfg-if v0.1.6
   Compiling unicode-segmentation v1.2.1
   Compiling unicode-width v0.1.5
   Compiling libc v0.2.43
   Compiling ucd-util v0.1.3
   Compiling lazy_static v1.2.0
   Compiling regex v0.2.11
   Compiling bitflags v1.0.4
   Compiling semver-parser v0.7.0
   Compiling serde v0.9.15
   Compiling utf8-ranges v1.0.2
   Compiling termcolor v0.3.6
   Compiling maplit v0.1.6
   Compiling quick-error v1.2.2
   Compiling textwrap v0.10.0
   Compiling memchr v2.1.1
   Compiling regex-syntax v0.5.6
   Compiling heck v0.3.0
   Compiling thread_local v0.3.6
   Compiling time v0.1.40
   Compiling dirs v1.0.4
   Compiling semver v0.6.0
   Compiling clap v2.32.0
   Compiling toml v0.3.2
   Compiling quote v0.6.10
   Compiling chrono v0.4.6
   Compiling aho-corasick v0.6.9
   Compiling syn v0.15.21
   Compiling structopt-derive v0.2.13
   Compiling structopt v0.2.13
   Compiling cargo-release v0.10.5
error: cannot find derive macro `StructOpt` in this scope
   --> src/main.rs:316:17
    |
316 | #[derive(Debug, StructOpt)]
    |                 ^^^^^^^^^

error: cannot find derive macro `StructOpt` in this scope
   --> src/main.rs:378:17
    |
378 | #[derive(Debug, StructOpt)]
    |                 ^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:321:5
    |
321 |     #[structopt(short = "c", long = "config")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:325:5
    |
325 |     #[structopt(short = "m")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:329:5
    |
329 |     #[structopt(long = "sign")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:333:5
    |
333 |     #[structopt(long = "dry-run")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:337:5
    |
337 |     #[structopt(long = "upload-doc")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:341:5
    |
341 |     #[structopt(long = "push-remote")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:345:5
    |
345 |     #[structopt(long = "skip-publish")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:349:5
    |
349 |     #[structopt(long = "skip-push")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:353:5
    |
353 |     #[structopt(long = "skip-tag")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:357:5
    |
357 |     #[structopt(long = "doc-branch")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:361:5
    |
361 |     #[structopt(long = "tag-prefix")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:365:5
    |
365 |     #[structopt(long = "dev-version-ext")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:369:5
    |
369 |     #[structopt(long = "no-dev-version")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:373:5
    |
373 |     #[structopt(long = "no-confirm")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:381:5
    |
381 |     #[structopt(name = "release")]
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error[E0658]: The attribute `structopt` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
   --> src/main.rs:379:1
    |
379 | #[structopt(name = "cargo")]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 18 previous errors

For more information about this error, try `rustc --explain E0658`.
error: failed to compile `cargo-release v0.10.5`, intermediate artifacts can be found at `/tmp/cargo-installW8ksCU`

Caused by:
  Could not compile `cargo-release`.

cargo-release is still displaying prompts incorrectly on my windows box (displaying some unsupported escape chars). Since cargo is using termcolor, I think cargo-release should do the same.

Cargo library provides a few apis for extension development. We will move onto that.

It'd be awesome if you could have a global config for all projects, like ~/.config/cargo-release/config.toml or something.

It looks like it will attempt to use the wrong version here.

I'm using --no-dev-version because I'm managing the version number myself, don't want cargo release to change and make a commit. Does this make sense?

Version in Cargo.toml is:

version = "0.9.0-alpha.1"

command is: cargo release --dry-run --no-dev-version

output:

cd .
git commit  -am (cargo-release) version 0.9.0
cd -
cargo publish
git tag -a 0.9.0 -m (cargo-release)  version 0.9.0 
git push origin --follow-tags

version: cargo-release-release 0.7.1

Thanks for this great plugin! I'm just missing a little piece: A way to change the commit messages this tool generates. It's just that I typically use a different style for my messages, and I'd love to keep messages in my repo consistent 😊

Besides, is there a configuration file for cargo release where I could add options such as --sign to make them permanent, for all contributors to a project?

no-dev-version is not read from the config file

Looks like it's missing here https://github.com/sunng87/cargo-release/blob/7af544590d751ca948aadbd95ba9aed1576af947/src/config.rs#L62

Hi.

When specifying a dependency with path, it is annoying to use cargo release because of the added suffix -pre.
It is an issue because you want to specify a version like "^1.2.3" which is incompatible with "1.2.4-pre".

Currently, I use the option --no-dev-version, but I need to manually bump the version.

I would like to be able to have automatic version bump, but without the -pre suffix.

Is this possible to do so?

Thanks!

I'd like to be able to use cargo-release to release pre-release versions of crates, for example 1.0.0-alpha.

Currently level can be unspecified, patch, minor, or major. In all cases any pre-release identifiers are removed. To support releasing a pre-release version, what I think would make the most sense would be to add a new value for level: pre, and an additional cmd-line and Cargo option: pre-release-identifiers, which would only be used when level is pre. This is not to be confused w/ the development-pre-release-identifier(s) that will be used (in step 6) when incrementing the version after the release.

This is a feature request to split the release action in two phases: a "commit" and a "publish" one. I'm going to detail my usecase below. I'm willing to start drafting the code for this myself, but I need some guidance on the design/UI points.

In other collaborative projects I've been involved, the process for a release is:

• a release manager checks that all milestoned bugs/epics/etc are done
• they open a dedicated branch for the release
• they run a script s1 to assemble the changelog and finalize it with editorial changes
• they run a script s2 which performs two commits:
  • a first one which bumps all version/references/etc to the actual release
  • a second one which goes back to the development cycle (e.g. -pre)
• this branch is submitted as a normal PR to be reviewed for typos and possible scripted mistakes
• after final approval, it is merged into master
• another script s3 performs the final steps:
  • checks out the real release commit (HEAD^), adds a tag, build all artifacts
  • push the tag to master and publish artifacts in all relevant places

While I don't want to automate all this complex and opinionated process via cargo-release, I would like to able to handle twe two main steps in there (creating the commits and pushing) in two separate phases. @sunng87 do you think it is meaningful to have here? How do you think the CLI should look like?

What about support of the Keep a Changelog format?

All you need to do is to replace this:

## [Unreleased]
### Added
- Stuff

[Unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.1.0...HEAD
[0.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.0...v0.1.0

with this:

## [Unreleased]

## [0.1.0] - 2017-06-20
### Added
- Stuff

[Unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.2.0...HEAD
[0.2.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.1.0...v0.2.0
[0.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.0...v0.1.0

 ## [Unreleased]
+
+## [0.1.0] - 2017-06-20
 ### Added
 - Stuff
 
-[Unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.1.0...HEAD
+[Unreleased]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.2.0...HEAD
+[0.2.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.1.0...v0.2.0
 [0.1.0]: https://github.com/olivierlacan/keep-a-changelog/compare/v0.0.0...v0.1.0

Some of the text output is invisible when using KDE Konsole with the solarized light theme. Having not used this program in some time, I initially thought cargo release was just hanging, but eventually figured out what was going on.

I haven't had this issue with any other programs, so perhaps the use of color should be revisited for this program.

I've been using cargo-release for publishing my various Rust crates and it's very useful, thanks! I recently configured things on the sccache repository to generate releases and publish binary artifacts from Travis / AppVeyor when I tag a release. This is working fine with Travis, but AppVeyor doesn't trigger a build on the tag. I looked into it a bit, and this seems to be the answer:
https://help.appveyor.com/discussions/questions/2133-deploy-setting-for-nuget#comment_39280964

Since cargo-release pushes both the tag and the new head of master at the same time, AppVeyor doesn't see the tag and so it doesn't trigger our deployment code:
https://github.com/mozilla/sccache/blob/d2c7f925adf0b105a9b87200129d57cf39439ada/appveyor.yml#L41

I think maybe the simple fix here would be to do two pushes: first push just the release tag, and then push the new head of master? (I am not confident that this would actually fix it, though!)

As discussed in #10 , we need an option to set git remote for the final push.

I believe it is currently possible to set only something like the following:
pre-release-hook = "./hook.sh"

I would like to do also, something like the following:
pre-release-hook = ["./hook.sh", "--my-arg-1", "--my-arg-2"]
or:
pre-release-hook = ["bash", "-e", "./hook.sh", "--my-arg-1", "--my-arg-2"]
and like the following (referring to cargo-make sub-command, which is a bit better than shell scripts):
pre-release-hook = ["cargo", "make", "some-target"]

Thanks for cargo-release. It's working great for me here.

Currently cargo-release uses a hard-coded identifier of pre when incrementing to the next pre-release version. As I understand the semver spec, alphanumeric pre-release identifiers sort based on ASCII sort order, so pre would sort as later than, for example, alpha or beta, which seems wrong.

One super-easy fix would be to change the hard-coded identifier to PRE, since the upper-case alphabet comes before the lower-case in ASCII, but allowing the identifier to be specified via cmd line option & Cargo.toml package.metadata.release probably makes more sense.

If you're open to this, I think I'd be able to get a PR done fairly quickly.

Thanks.

Simply add an option to replace mypackage = "(old version)" with the new version in the README.MD, because else I'm likely to forget it.

I would love to have a dry run option so I can see what it will do before it does it. I was very nervous running this program for the first time, but it worked great!

Prerelease versions wreak havoc on internal deps,

for example ndarray-rand depends on ndarray = "0.7". A prerelease version like 0.7.1-pre can't fill the version requirement "0.7", so it fails to compile in tree.

I've performed a release yesterday, which got quite nicely, but failed after quite whole the process was done (crates.io was updated, the tag was created)

Unfortunatly, the release ended with the following error message

 cargo release Fatal: IO Error: Accès refusé. (os error 5)

Do cargo release requires admin account ?

It would be handy if there was a way to only upload the documentation if the crate was already uploaded.

Also, I think at this point it'd be nice to have a per-repo config file for such things.

When publishing this, I saw this error:

brian@ip-10-234-25-118:~/dev/rust-sha2⟫ cargo release
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Packaging sha2 v0.1.0 (file:///home/brian/dev/rust-sha2)
   Verifying sha2 v0.1.0 (file:///home/brian/dev/rust-sha2)
    Updating registry `https://github.com/rust-lang/crates.io-index`
   Compiling rustc-serialize v0.3.19
   Compiling sha2 v0.1.0 (file:///home/brian/dev/rust-sha2/target/package/sha2-0.1.0)
   Uploading sha2 v0.1.0 (file:///home/brian/dev/rust-sha2)
Starting next development iteration 0.1.1-pre
Fatal: IOError
third party subcommand `cargo-release` exited unsuccessfully

To learn more, run the command again with --verbose.

Hey there,

I'm not sure whether this is strictly an issue, but it took me some time to work out and seems like a bit of a pain.

When cargo release X is run the version is bumped, the crate is published, then the version is again bumped to a development version. As cargo expects patch versions to match, this final bump means that you can no longer use [patch] overrides against the currently published library version for testing (without reverting the crate version in the patched crate's Cargo.toml).

This results in errors like:

warning: Patch `rr-mux v0.4.1-alpha.0 (/home/ryan/projects/rr-mux)` was not used in the crate graph.

Where the project cargo.toml contains:

[dependencies]
rr-mux = "0.4.0"
...

[patch.crates-io]
rr-mux = { path = "../rr-mux" }

One fix is to always run cargo release with --no-dev-version to avoid the problem.

My suggestion would be that that the second development version bump should be opt in, I didn't expect it to happen, but, either way there's now some documentation for anyone else who has the same problem.

The new [badges] section has a branch to specify which branch / tag's status should be displayed on crates.io. When cargo-release bumps the version and creates the git tag, it could also update the branch specifier for every badge in this section to the git tag of the new release; then that the manifest of the published crate will link to the badge for that release.

Refs:

rust-lang/crates.io#504
rust-lang/cargo#3546
http://doc.crates.io/manifest.html#package-metadata
https://www.integer32.com/2017/01/20/categories-and-ci-badges.html

Is it possible to disable git tags?

Add command line option to create a minor/major release

Most tools in the rust ecosystem use a config file separate to Cargo.toml. For example the rls uses the rls.toml for configuration and rustfmt uses the rustfmt.toml. In my opinion it would be much cleaner to have a release.toml (or something) for configuring this tool.

Tag prefix is useful when a few crates shares a single repository and should be tagged individually.

In a workspace, I need to define my dependencies as dep = { path = "../dep", version = "0.1.0" } but I forget (until cargo publish) to update the versions for my path dependencies (and it is really annoying).

I think building this into cargo-release would be a big help.

I view this as a subset of the work for #66. While that is for releasing an entire workspace, this will help with releasing parts of a workspace (and is needed for the entire workspace).

Configuration

• What to do on path dependency
  • verify
  • bump to latest (has to check crates.io because local path dependency has probably been bumped post-publish)
  • bump to semver compatible version

Add an option to set branch for document. Currently this is hard-coded as gh-pages but it would be great to support customized branch, for gitlab.

If git is not installed, then any command other than --help will fail with this unhelpful error message:

> cargo release --dry-run
Fatal: IO Error: No such file or directory (os error 2)

It would be far better for cargo-release to print the name of the file that wasn't found. As is, I had to use ktrace to find out.

Hello,

thank you for cargo release ❤️ I'm very happy with it, and I like the prerelease hook feature.

There's just a little issue with it: cargo release unfortunately discard the exit code of the hook.

I can use the hook to modify files and add them to the git index, but I can't make any checks or call commands that could fail, because the prerelease hook can't abort the release. Even if it signals an error with a non-zero exit code, cargo release continues.

I think cargo release should abort the release and not commit anything if the prerelease hook exits with a non-zero exit code.

It's easier in CI to work with cmd line arguments as oppose to file configs. I'd like to create a CI job to release my projects following the same release process.

Any config that you specify in a file should also be a command line argument

Reproduction: https://github.com/jonas-schievink/xml-rpc-rs/tree/af9fca89c41cc4f4a8f8480274de372f0be15117

$ cargo release --dry-run patch
...
Creating git tag xmlrpc-0.13.1

I don't think there should be a tag prefix xmlrpc-. The readme says:

For single-crate repository, we will use version number as git tag name.

This used to work, so this might be a regression in cargo-release.

Additionally, the repository sets tag-message = "{{version}}", which should override cargo-release's default in any case, right? At least that's what I gather from the readme.

(tested with cargo-release 0.11.1 and 0.11.0)

Hi,
I have a workspace layout like this:

workspace_root/
+- Cargo.toml
|    [workspace]
|    members = [ "project", ...]
+- Cargo.lock
+- project/
|  +- .git/
|  +- Cargo.toml
|  |    [package]
|  |    name = "project"
|  |    version = "0.1.0"
|  |    ...
|  +- src/
+ ...

when I run cargo release --level patch inside project/ (for example),
I get something like this:

$ cargo release --level patch
Release version 0.1.1 ? [y/N] y
Update to version 0.1.1 and commit
Fatal: IOError

I have looked into the source and found out, that config::rewrite_cargo_version tries to read the Cargo.lock file from the current directory.
As a workaround, I have copyed the Cargo.lock file from the workspace to the project, and the cargo-release worked.

The tag prefix can be set by passing --tag-prefix <prefix>, but the same doesn't seem to be possible by setting a [package.metadata.release] option in Cargo.toml. At least that feature doesn't seem to be documented in the README (unless I missed it).

I tried setting the tag-prefix and prefix options, but both resulted in an error message.

I love the idea of having a changelog, and I would like to maintain this changelog during build using git journal.

More precisely, I would like to have the CHANGELOG.md file having the new section text to be the content of git journal, and also having git journal set as commit text (which, as far as I understand) in the releases page of GitHub.
Unfortunatly, it seems like I can only use a small set of variables in pre-release-replacements. How can I do that ?

It would be handy to have integration between cargo-release and https://github.com/rust-lang-nursery/rust-semverver

Before you hit NO! on your reviewer-keyboard, please let me explain 😉

The Atom editor has a package management tool called apm. It was build for package management but it also helps you publishing atom packages. As it is explained in here the tool has the following command structure:

$ apm publish <major | minor | patch>

I find this structure really compelling because it kinda forces you to use the tool for versioning and it keeps versioning in particular very organized. So I would like to see a simillar structure in this tool:

$ cargo publish <major | minor | patch>

Add an option to enable doc upload on cargo-release

The semver specs defines a build metadata parameter suffix that can be added to a version, separated by a +. Ex: 0.1.0+stable.2017-07-21. This value is completely ignored for version comparison, and is only used to add information regarding the build.

It would be nice to be add a --metadata option to cargo release to specify this optional value when publishing a release.

In workspace projects, it is often desired to create coordinated releases with all package versions bumped at the same time. This includes upgrading versions in dependent crates. It would be great to have some sort of workspace flag, that performs all upgrades in a single commit (and tag).

Maintainer Notes

Steps

• Make core functionality independent of CWD
• Properly update lock file in a workspace
• #77 Verify / update corresponding version for path dependencies
• Create clap-cargo to at least contain workspace flags, making the processing of cargo-metadata reusable for other plugins
• #93 Figure out config semantics
• Support processing workspaces

Capturing the original discussion from nix-rust/nix#595.

As one of the last steps in a release process, there is often the need of semi-automatically generating a changelog.

I'd be better personally happy in having some field to specify a custom binary/script, and some calling convention to follow (e.g. to know about previous and new version, etc.). That way I could extend the process with further logic without making cargo-release too opinionated, and even introduce some interactive action in the middle for a final cosmetic pass.

cargo release already pushes zip/.tar.gz in releases page of GitHub and this is cool.
But for crate producing an executable binary, it would be better to have release executable pushed to GitHub. How can we do that ?

Hi,

Nice plugin.

I have CI (travis, Azure) that trigger some steps (build app + zip and upload to repository / github releases) only if the current bug is on a tag.
But cargo-release git push after the bump version. So the build of the released version (and its deployment) is not triggered and done.

Do you plan this features (or accept PR) to do it ?

As I workaround, I though to redo the workflow of cargo-release with few tasks in cargo-make (I already use cargo-make to drive ci tasks, and call/wrap cargo-release). My wip project: https://github.com/ffizer/ffizer/

Releasing is an important process that you don't do all the time, so there could be a confirmation like Changing version 1.2.4 -> 1.3.0? [y/n].

Ever heard of StructOpt? It's a crate for command line argument parsing and validation, that makes things significantly easier,
crate: https://crates.io/crates/structopt
docs: https://docs.rs/structopt

pre-release-hook documentation doesn't state that this flag is to be put in release.toml, which consumes a little time :-)

release.toml is silently ignored when it contains invalid toml. Ideally the error should be fatal or at least logged.