Add an option to not error if nothing to publish (for idempotent operations)?

[sunshowers]

Hi there --

I noticed that cargo-release 0.22 changed things so that it's now an error if there's nothing to publish: 4783fda

I'm wondering if it would be possible to have a flag which makes it so that it no longer errors if there's nothing to publish. My use case is that I'm releasing a bunch of independently versioned crates and I'd like to move towards using cargo-release in CI to do the publishing. To avoid race conditions, I'd like the publish step of each crate to publish everything that can be published, to avoid race conditions between different release jobs. This is effectively an idempotent operation, which shouldn't fail if there's nothing to publish.

Alternatively, I could potentially say that if the exit code is 2, treat it as success. Does the exit code 2 always mean "nothing to publish" as part of the documented command-line interface?

Thanks!

[epage]

My intent with #542 (which I didn't spell out) was to allow jobs to trigger behavior based on nothing being released (or something being released), including reporting in PRs if it will cause a release to happen. I then extended it to all steps to be consistent.

Exit Code 2 is "bad input" and will overlap with clap errors.

Depending on your situation, concurrency might be of interest (since you mentioned race conditions).

If we still want to move forward with this, the questions would be

• Should we make this a more distinct exit code or make it configurable?
• What should the flag look like? Both in naming and whether it just switches error behavior or accepts the desired exit code (with a default)

[sunshowers]

Thanks!

I hadn't thought about using the concurrency setting. I think unfortunately in my use it would still be subject to races depending on which job goes first; it would be best to have the idempotency available.

It would definitely be OK to have a documented exit code for "nothing to do". It's common to use exit code 1 for this (e.g git commit), though if there's a chance that will clash with something some other code would be fine too (eg 99).

[sunshowers]

BTW, this use case:

to allow jobs to trigger behavior based on nothing being released (or something being released), including reporting in PRs if it will cause a release to happen

would definitely benefit from a defined exit code.

[sunshowers]

Any thoughts about this? This is blocking moving to a newer cargo-release (my jobs are currently pinned to 0.21.4).

If we agree on a way forward I'm happy to implement it.

[sunshowers]

I just ran into another race: if cargo-release attempts to publish the same version of a crate in two separate jobs, the one that loses the race will fail, even though in an idempotent mode it should keep working.

This inclines me to believe that maybe a --idempotent flag really is the better way to do things -- it can deal with exit code issues as well as races like that.

[epage]

@sunshowers for another month or so I have limited availability and am mostly doing quick triages or work on a couple of focus areas. This isn't a quick triage (no clear design atm) and not the priority area, so I'm unlikely to get to this for a bit.

[sunshowers]

OK, I'm going to go ahead and implement my preferred design in a personal fork. I'd be happy to work on upstreaming it whenever you have the time :)