Have you raised this on community forums? Or first time
Have you raised this on community forums? Or first time
KNo I haven't, haven't used the forums in a while. Most times I stumble across a community forum post via google it is unresolved with no answer at all... On the other hand here is (mostly) always someone to help or give a hint in the right direction.
CDid you publish the worker via wrangler to start with/try wrangler now?
The Jurisdiction docs only mention it being possible to bind to a eu bucket via wrangler and the jurisdiction param
https://developers.cloudflare.com/r2/reference/data-location/#using-jurisdictions-from-workers
The Jurisdiction docs only mention it being possible to bind to a eu bucket via wrangler and the jurisdiction param
https://developers.cloudflare.com/r2/reference/data-location/#using-jurisdictions-from-workers
Learn how the location of data stored in R2 is determined and about the different available inputs that control the physical location where objects in …
KIt is deployed via wrangler and has the jurisdiction param. It has worked fine since october
Cah ok makes sense then, I don't think it ever displayed right in the UI then/let you pick it from there.
If you wrangler tail, what's the exact error its throwing? It might be helpful to just try redeploying it as well
If you wrangler tail, what's the exact error its throwing? It might be helpful to just try redeploying it as well
KCan I trigger a schedule event via wrangler? Otherwise I have to wait for the next scheduled run to happen
CIn Dev you can, not in prod. In prod your best bet is to make a secret endpoint which calls the scheduled event
KRe-deploying seems to have fixed it. But: Something must have happened on 2023-12-24 that caused the binding to stop working. Maybe someone from CF might be interested in it.
Cyea that's weird. I don't see anything on Workers or R2 change log around that date.
Do you have any deployments for that worker (under the deployments tab) on that date? Or was the last time you modified it before that?
Do you have any deployments for that worker (under the deployments tab) on that date? Or was the last time you modified it before that?
KNo, nothing. Last deployment before the issue started was on 2023-11-17. Even had a look at my audit log to see if something happened at all, nothing.
KOh, I see that on 2023-12-23 various certificates related to the worker were renewed. Both
*.{worker-name}.{subdomain}.workers.dev and *.{zone-domain}.tld.
DWe use Cloudflare Access to protect Workers that only have a few users (usually 1-2).
UYou can talk with sales about your use case and see if its something they can increase limits on.
DWhy do all my Workers show as
Last modified 7 days ago now?Dwhen I actually click them, I see the last deployment was months ago
CDid you perhaps migrate to Standard recently?
CI think that caused that.. if i remember right?
Dyes, but I thought it was more than a week ago
Ddoes that show up in the audit logs?
CI have no idea sorry, didn't check at the time and way too long ago now
Dhmm you're probably right
DIs there a notification like this, but for Workers?
DCan you have multiple Tail Workers attached to a single Worker?
CWith smart placement, I have a worker with it enabled that proxies fetch requests from a Page function that is bound to it.
The proxy then calls our azure endpoints which are in EU. We do cname our host name e.g. api.example.com to azure via CF. I have made a few hundred requests however placement is still local. Is there no way to manually assign location?
The proxy then calls our azure endpoints which are in EU. We do cname our host name e.g. api.example.com to azure via CF. I have made a few hundred requests however placement is still local. Is there no way to manually assign location?
RHow can solve this issue
MIs there a way to use the Wrangler GH Action to publish different branches to different environments of the same worker? Or is it easier to just set up a stage worker and a live worker?
KYou can pass an environment but it has to already exist in Wrangler.toml
MAha so you mean as long as I have stage and live set up as envs in the TOML, I can then configure the Action to push one branch to one env and another branch to the other?
KYep
MThanks. Is there an example anywhere of the GH Workflow file showing this multi-branch/env approach? I'm unsure how to adapt the example file to do this.
MDo I just repeat the branches reference? i.e.
MAnd how do I associate the names of the branches with the names of my Worker envs - or must they match?
KMThanks. So the full file would be as follows? Could you possibly elaborate on what precisely that
with/environment part does? I know it's setting env vars, but what is the result of those operators i.e. the statement's intention?MAppreciate the help. (Also, why do I need to get involved in specifying Linux versions? Is that just for GH not CF?)
Kyep
Kyou need to tell GitHub what to run the Actions on
Ksame as if you wanted a Docker container, you still need to tell it that you want
ubuntu or debian or alpine, etc
Kenvironment needs to be under the same with as apiTokenKwith are inputs that the action (in this case wrangler-action) acceptsMAha, thanks. So:
MAnd presumably
secrets.CLOUDFLARE_API_TOKEN refers to a GH secret, not a Worker secretKYep
KIf you want to publish your Worker with secrets from GitHub, you use
secretswithKKbut otherwise,
${{ secrets.CLOUDFLARE_API_TOKEN }} is just to say "use the API token from my GitHub secret called CLOUDFLARE_API_TOKEN"MAh that's interesting - so you're saying specifying secrets in this way is an alternative to creating secrets via Wrangler i.e.
secret put?