-
Notifications
You must be signed in to change notification settings - Fork 594
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
Add support for listing R2 buckets #1050
Conversation
Provide the ability to create the `RequestError`, etc types in other packages with the underlying Error type. Useful in our code for mocking these error types. Add the `InternalErrorCodeIs` to these errors as well to simplify checking the internal codes when working with these types.
changelog detected ✅ |
once the API is stable, the service team document it and it ends up on api.cloudflare.com |
@jacobbednarz harping on this again. The API endpoints are "documented" right here in code: https://github.com/cloudflare/wrangler2/blob/main/packages/wrangler/src/r2.ts#L14-L24 Why are there ongoing delays between making an API endpoint public in code and making the documentation public? The blog proudly exclaims that you're going to stop doing that: https://blog.cloudflare.com/content-as-a-product/
|
@sodabrew this is your first and only warning that your comment is disrespectful and unacceptable. I highly recommend reviewing the project's code of conduct as violations can result in temporary or permanent exclusion from the project. The wrangler2 codebase (and other tools released by the service teams) is not public documentation and is not suitable for determining an API contract for the SDKs. The team is usually controlling both sides (tool and API) so they can make sweeping changes without breaking integrations; that cannot be the same for the SDKs since we have customers relying on certain behaviours. |
I'm sorry, thank you, getting on the wrong side certainly does me no good towards sharing a goal of using a great product.
This is succinctly describing the situation. I appreciate being on the same page. I want to share that this is exactly my concern as a customer: if I build deployment tooling around wrangler2 and it changes suddenly with a coordinated release and API change, deployment workflows can be broken until an update is performed. |
i'm in the process of adding a document outlining the endpoint support policy since it's a fairly common question (both internally and externally). hopefully that will clarify things a bit for reference. |
…-lockdown-create-update
Co-authored-by: Jacob Bednarz <[email protected]>
…field-suppress
This commit does two things: 1) Moves all tooling related dependencies and functionality into `internal/` to mark the code as not intended to be used outside of the package (which I found forks doing 🤦) 2) Reduces the dependency footprint for library-only use. Fixes cloudflare#1057 Fixes cloudflare#1025
Co-authored-by: Jacob Bednarz <[email protected]>
…loudflare#1040) Co-authored-by: Jacob Bednarz <[email protected]>
Description
Added the ability to list R2 buckets. A recent change (#1028) added support for creating and deleting R2 buckets but was missing the ability to list R2 buckets. This change adds support for listing R2 buckets.
Has your change been tested?
Enhanced r2_bucket_test.go with an additional test (TestR2_ListBuckets) to list R2 buckets. Also verified this against an active cloudflare account.
Types of changes
What sort of change does your code introduce/modify?
Checklist:
Notes
I could not find the repo for the api definition at api.cloudflare.com in order to update the documentation myself. I'm happy to do that if someone can give me a pointer to it. Also, how does this API path become a publicly documented and stable API? Thanks.