failing to release with more than 30 crates

[rnbguy]

The concerning code is below:

https://github.com/crate-ci/cargo-release/blob/4b09269f320d2186b58a233306ecd6c1b848b746/src/steps/mod.rs#L251-L261

Not sure, how this hard-coded number, 30, is derived in #545. AFAIK, it is much higher than 30 (for publishing existing crates). Can we at least make it flexible - maybe via an environment variable?

[epage]

Not sure, how this hard-coded number, 30, is derived in https://github.com/crate-ci/cargo-release/pull/545. AFAIK, it is much higher than 30 (for publishing existing crates). Can we at least make it flexible - maybe via an environment variable?

The limits came from an email someone got from the crates.io team

The rate limit for creating new crates is 1 crate every 10 minutes, with a burst of 5 crates.

The rate limit for new versions of existing crates is 1 per minute, with a burst of 30 crates, so when releasing new versions of these crates, you shouldn't hit the limit.

It's not particularly secret, we just don't publish it other than in the code because it's subject to change. The responses from the rate limited requests on when to try again contain the most accurate information.

See https://github.com/crate-ci/cargo-release/issues/483#issuecomment-1173038971

They could have adjusted the base limits since 2022. They also adjust the limits for known special cases.

[epage]

I can see putting the limits in the config file as the limits will be associated with a given registry and a given publisher / set of packages. It shouldn't be changing from run to run, so not CLI or env.

[rnbguy]

Totally okay with putting this in cargo-release config :+1:

[workspace.metadata.release]
ratelimit = { existing = 50 }

I would be up for a PR. Just let me know :slightly_smiling_face:

[epage]

Seems reasonable. Go for it :)