Don't know if it is a better fit here or in #r2: I noticed that one of my workers started to throw e

Kkev-ac Don't know if it is a better fit here or in #r2: I noticed that one of my worker...

C

Cyb3r-Jak3•1/24/24, 2:45 PM

Have you raised this on community forums? Or first time

CCyb3r-Jak3 Have you raised this on community forums? Or first time

K

kev-acOP•1/24/24, 2:46 PM

No 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.

Kkev-ac Don't know if it is a better fit here or in #r2: I noticed that one of my worker...

C

Chaika•1/24/24, 2:48 PM

Did 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

Data location · Cloudflare R2 docs

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 …

CChaika Did you publish the worker via wrangler to start with/try wrangler now? The Juri...

K

kev-acOP•1/24/24, 2:49 PM

It is deployed via wrangler and has the jurisdiction param. It has worked fine since october

Kkev-ac It is deployed via wrangler and has the jurisdiction param. It has worked fine s...

C

Chaika•1/24/24, 2:51 PM

ah 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

CChaika ah ok makes sense then, I don't think it ever displayed right in the UI then/le...

K

kev-acOP•1/24/24, 2:51 PM

Can I trigger a schedule event via wrangler? Otherwise I have to wait for the next scheduled run to happen

C

Chaika•1/24/24, 2:53 PM

In Dev you can, not in prod. In prod your best bet is to make a secret endpoint which calls the scheduled event

K

kev-acOP•1/24/24, 2:56 PM

Re-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.

Kkev-ac Re-deploying seems to have fixed it. But: Something must have happened on 2023-1...

C

Chaika•1/24/24, 2:58 PM

yea 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?

CChaika yea that's weird. I don't see anything on Workers or R2 change log around that d...

K

kev-acOP•1/24/24, 3:00 PM

No, 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.

K

kev-acOP•1/24/24, 3:05 PM

Oh, I see that on 2023-12-23 various certificates related to the worker were renewed. Both

*.{worker-name}.{subdomain}.workers.dev

*.{worker-name}.{subdomain}.workers.dev

and

*.{zone-domain}.tld

*.{zone-domain}.tld

.

SSz Hey, is there a recommended way to protect workers with api keys? I'm fairly new...

D

dave•1/24/24, 4:42 PM

We use Cloudflare Access to protect Workers that only have a few users (usually 1-2).

U

Unsmart•1/24/24, 10:15 PM

You can talk with sales about your use case and see if its something they can increase limits on.

D

dave•1/25/24, 12:44 AM

Why do all my Workers show as

Last modified 7 days ago

Last modified 7 days ago

now?

D

dave•1/25/24, 12:44 AM

when I actually click them, I see the last deployment was months ago

Ddave Why do all my Workers show as `Last modified 7 days ago` now?

C

Chaika•1/25/24, 12:46 AM

Did you perhaps migrate to Standard recently?

C

Chaika•1/25/24, 12:46 AM

I think that caused that.. if i remember right?

CChaika Did you perhaps migrate to Standard recently?

D

dave•1/25/24, 12:46 AM

yes, but I thought it was more than a week ago

CChaika Did you perhaps migrate to Standard recently?

D

dave•1/25/24, 12:47 AM

does that show up in the audit logs?

C

Chaika•1/25/24, 12:48 AM

I have no idea sorry, didn't check at the time and way too long ago now

D

dave•1/25/24, 12:50 AM

hmm you're probably right

D

dave•1/25/24, 12:52 AM

Is there a notification like this, but for Workers?

D

dave•1/25/24, 1:27 AM

Can you have multiple Tail Workers attached to a single Worker?

C

charl.dev•1/25/24, 4:53 AM

With 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?

R

Rahul Raikwar•1/25/24, 9:40 AM

How can solve this issue

M

Mitya•1/25/24, 10:38 AM

Is 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?

K

kian•1/25/24, 10:40 AM

You can pass an environment but it has to already exist in Wrangler.toml

M

Mitya•1/25/24, 10:41 AM

Aha 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?

K

kian•1/25/24, 10:41 AM

Yep

M

Mitya•1/25/24, 10:43 AM

Thanks. 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.

M

Mitya•1/25/24, 10:43 AM

Do I just repeat the branches reference? i.e.

on:
  push:
    branches:
      - main
      - stage

on:
  push:
    branches:
      - main
      - stage

on:
  push:
    branches:
      - main
      - stage

on:
  push:
    branches:
      - main
      - stage

M

Mitya•1/25/24, 10:45 AM

And how do I associate the names of the branches with the names of my Worker envs - or must they match?

K

kian•1/25/24, 10:49 AM

on:
  push:
    branches:
      - main
      - stage

# ...

with:
  environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}

on:
  push:
    branches:
      - main
      - stage

# ...

with:
  environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}

on:
  push:
    branches:
      - main
      - stage

# ...

with:
  environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}

on:
  push:
    branches:
      - main
      - stage

# ...

with:
  environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}

K

kian•1/25/24, 10:49 AM

https://docs.github.com/en/actions/learn-github-actions/expressions#example

M

Mitya•1/25/24, 11:02 AM

Thanks. So the full file would be as follows? Could you possibly elaborate on what precisely that

with/environment

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?

name: Deploy

on:
  push:
    branches:
      - main

with:
  environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}

name: Deploy

on:
  push:
    branches:
      - main

with:
  environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}

name: Deploy

on:
  push:
    branches:
      - main

with:
  environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}

name: Deploy

on:
  push:
    branches:
      - main

with:
  environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        uses: cloudflare/wrangler-action@v3
        with:
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}

M

Mitya•1/25/24, 11:02 AM

Appreciate the help. (Also, why do I need to get involved in specifying Linux versions? Is that just for GH not CF?)

K

kian•1/25/24, 11:09 AM

yep

K

kian•1/25/24, 11:09 AM

you need to tell GitHub what to run the Actions on

K

kian•1/25/24, 11:09 AM

same as if you wanted a Docker container, you still need to tell it that you want

ubuntu

ubuntu

or

debian

debian

or

alpine

alpine

, etc

MMitya Thanks. So the full file would be as follows? Could you possibly elaborate on wh...

K

kian•1/25/24, 11:10 AM

environment

environment

needs to be under the same

with

with

as

apiToken

apiToken

K

kian•1/25/24, 11:10 AM

with

with

are inputs that the action (in this case

wrangler-action

wrangler-action

) accepts

K

kian•1/25/24, 11:11 AM

https://github.com/cloudflare/wrangler-action/blob/08514fdeceb93b6f0e9325780b4438218fcbe1c0/action.yml#L21-L22

M

Mitya•1/25/24, 11:15 AM

Aha, thanks. So:

name: Deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        uses: cloudflare/wrangler-action@v3
        with:
          environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}

name: Deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        uses: cloudflare/wrangler-action@v3
        with:
          environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}

name: Deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        uses: cloudflare/wrangler-action@v3
        with:
          environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}

name: Deploy

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - uses: actions/checkout@v3
      - name: Deploy
        uses: cloudflare/wrangler-action@v3
        with:
          environment: ${{ github.ref_name == 'main' && 'worker-env-for-main' || 'worker-env-for-not-main' }}
          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}

M

Mitya•1/25/24, 11:15 AM

And presumably

secrets.CLOUDFLARE_API_TOKEN

secrets.CLOUDFLARE_API_TOKEN

refers to a GH secret, not a Worker secret

K

kian•1/25/24, 11:15 AM

Yep

K

kian•1/25/24, 11:15 AM

If you want to publish your Worker with secrets from GitHub, you use

secrets

secrets

in

with

with

K

kian•1/25/24, 11:16 AM

jobs:
  deploy:
    steps:
      uses: cloudflare/wrangler-action@v3
      with:
        apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
        secrets: |
          SECRET1
          SECRET2
      env:
        SECRET1: ${{ secrets.SECRET1 }}
        SECRET2: ${{ secrets.SECRET2 }}

jobs:
  deploy:
    steps:
      uses: cloudflare/wrangler-action@v3
      with:
        apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
        secrets: |
          SECRET1
          SECRET2
      env:
        SECRET1: ${{ secrets.SECRET1 }}
        SECRET2: ${{ secrets.SECRET2 }}

jobs:
  deploy:
    steps:
      uses: cloudflare/wrangler-action@v3
      with:
        apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
        secrets: |
          SECRET1
          SECRET2
      env:
        SECRET1: ${{ secrets.SECRET1 }}
        SECRET2: ${{ secrets.SECRET2 }}

jobs:
  deploy:
    steps:
      uses: cloudflare/wrangler-action@v3
      with:
        apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
        secrets: |
          SECRET1
          SECRET2
      env:
        SECRET1: ${{ secrets.SECRET1 }}
        SECRET2: ${{ secrets.SECRET2 }}

K

kian•1/25/24, 11:16 AM

but otherwise,

${{ secrets.CLOUDFLARE_API_TOKEN }}

${{ secrets.CLOUDFLARE_API_TOKEN }}

is just to say "use the API token from my GitHub secret called

CLOUDFLARE_API_TOKEN

CLOUDFLARE_API_TOKEN

"

Don't know if it is a better fit here or in #r2: I noticed that one of my workers started to throw e

Similar Threads