changelog detected ✅

Codecov Report

Merging #1014 (ee5e98e) into master (6c5ea4a) will increase coverage by 0.66%.
The diff coverage is 58.97%.

@@            Coverage Diff             @@
##           master    #1014      +/-   ##
==========================================
+ Coverage   49.06%   49.72%   +0.66%     
==========================================
  Files         108      115       +7     
  Lines       10428    10862     +434     
==========================================
+ Hits         5116     5401     +285     
- Misses       4200     4299      +99     
- Partials     1112     1162      +50     

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

Working on tests next.

@jacobbednarz should I switch the arguments to be inside a struct? Some of the methods use a strict while others take direct arguments. I'm leaning towards switching to the struct pattern. Let me know!

check out https://github.com/cloudflare/cloudflare-go/blob/master/docs/experimental.md, #1028, and https://github.com/cloudflare/cloudflare-go/blob/master/tunnel.go for prior art on how we should be adding new methods.

@jacobbednarz Updated per your examples, please review!

It seems like cloudflare.ZoneIdentifier could be used for this new call, but there's no other user of it in workers.go. https://github.com/cloudflare/cloudflare-go/blob/master/docs/experimental.md

In workers.go, I followed the example of DeleteWorker, DownloadWorker, etc. that have ZoneID in the respective params structs.

It seems like cloudflare.ZoneIdentifier could be used for this new call, but there's no other user of it in workers.go.

there are currently no other implementation of ResourceContainer in the workers methods because they 1) predate the change 2) are pretty messy when it comes to what can live at what resource level. it hasn't been touched (but really should be improved) as the Workers API has evolved quite a bit since it was introduced and most of it is no longer needed.

going forward, we want to use the updated method signature for all new methods to help future proof against these issues.

going forward, we want to use the updated method signature for all new methods to help future proof against these issues.

Just to be clear, does that mean I should add the new method using the new style in a manner differently than my latest commit, or that you'll circle back to workers.go at a later date and redo all the method signatures in one go?

PS - I would expect to squash all commits in this PR, let me know if you'd like to do that as part of a review and merge or if I should force push my branch. I am very comfortable with rebase workflow, so this is no hardship at my end.

does that mean I should add the new method using the new style in a manner differently than my latest commit

sorry if it wasn't clear. you should do this (i'll add a note inline as a reminder).

PS - I would expect to squash all commits in this PR, let me know if you'd like to do that as part of a review and merge or if I should force push my branch. I am very comfortable with rebase workflow, so this is no hardship at my end.

no need, i'm happy to merge/squash at the end.

thanks! appreciate the effort here!

Thank you!

This functionality has been released in v0.47.0.

For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template. Thank you!