You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Add a delay after every crate (when uploading >30 crates) to ensure that there is only 1 crate per minute and the rate limit is never hit. This is simple, but possibly unnecessarily slow.
Try to upload as many crates as possible and retry every few minutes afterwards.
Re-implement the rate limiting logic within cargo-release, that is, keep track of when crates were published and figure out when the next crate can be published.
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.
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.
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!
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.
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 ifcargo-release
will continue once it can. I can see various solutions to this:cargo-release
, that is, keep track of when crates were published and figure out when the next crate can be published.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: #483, #584
The text was updated successfully, but these errors were encountered: