Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Delay for rate limit #726

Open
tertsdiepraam opened this issue Nov 16, 2023 · 3 comments
Open

Delay for rate limit #726

tertsdiepraam opened this issue Nov 16, 2023 · 3 comments
Labels
enhancement Improve the expected

Comments

@tertsdiepraam
Copy link

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.

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

Relevant issues: #483, #584

@epage
Copy link
Collaborator

epage commented Nov 16, 2023

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?

@epage epage added the enhancement Improve the expected label Nov 16, 2023
@tertsdiepraam
Copy link
Author

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
Copy link
Collaborator

epage commented Nov 16, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improve the expected
Projects
None yet
Development

No branches or pull requests

2 participants