crate-ci / cargo-release

Cargo subcommand `release`: everything about releasing a rust crate.
Apache License 2.0
1.33k stars 112 forks source link

Delay for rate limit #726

Open tertsdiepraam opened 11 months ago

tertsdiepraam commented 11 months ago

Hi! If I understand correctly, this tool will abort when trying to upload more crates than crates.io allows. However, I'd love to use this for uutils, where we have a lot of crates (~100) that we publish at the same time. We currently have a big unwieldy bash script to publish the crates, which I'd love to off-load to cargo-release. I don't mind waiting for the rate limit if cargo-release will continue once it can. I can see various solutions to this:

However, this should probably also be configurable since there are projects that do not have to adhere to these limits. For the first option, the delay could be some config option.

I'm happy to implement any solution you see fit!

Relevant issues: https://github.com/crate-ci/cargo-release/issues/483, https://github.com/crate-ci/cargo-release/issues/584

epage commented 11 months ago

Looks like we never removed PUBLISH_GRACE_SLEEP so that can be used as a workaround until something is implemented (unit is seconds).

I believe individual projects can ask to get the rate limit lifted, so we also likely want to make the rate limit values configurable (including backoff time). That would also allow people to workaround it if our rate limit configuration is stale.

We could have a --rate-limit=<sleep|error>. Seems like the caller should be aware and so we should default to error and they have to override it on the command line, rather than also putting in the config.

Thoughts?

tertsdiepraam commented 11 months ago

I agree that it should be configurable. For large projects, this would be required every time, so a configuration option would make sense, I think. But I'd be happy with a command line option too!

epage commented 11 months ago

so a configuration option would make sense

Even if its required every time, I think I'd still want an opt-in every time so someone doesn't run it without thinking and have to worry about canceling because it'll take 30 minutes and they have to shutdown in 10.

This is also making me think that the error mode should have en estimate for how long it would take and the sleep mode should show a warning with that time before the confirmation prompt.