Re-deploying seems to have fixed it. But: Something must have happened on 2023-12-24 that caused the

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

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

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

*.{zone-domain}.tld

*.{zone-domain}.tld

*.{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

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

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

debian

debian or

alpine

alpine

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

environment

environment needs to be under the same

with

with

with

with as

apiToken

apiToken

apiToken

apiToken

K

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

with

with

with

with are inputs that the action (in this case

wrangler-action

wrangler-action

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

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

secrets

secrets in

with

with

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 }}

${{ 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

CLOUDFLARE_API_TOKEN

CLOUDFLARE_API_TOKEN"

M

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

Ah that's interesting - so you're saying specifying secrets in this way is an alternative to creating secrets via Wrangler i.e.

secret put

secret put

secret put

secret put?

K

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

Yep

M

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

Legendary. Thanks for your help.

M

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

On a different topic, if I don't specify the

--env

--env

--env

--env arg when doing

wrangler secret put

wrangler secret put

wrangler secret put

wrangler secret put, is the secret available to all envs (in my TOML), or default to just one env in particular?

K

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

defaults to the Worker name that’s in the top level

K

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

envs are separate Workers, it’s purely a Wrangler abstraction

M

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

But if I create a secret with the

--env

--env

--env

--env arg, that secret will be available only to the env specified, right? So

wrangler secret put foo --env "stage"

wrangler secret put foo --env "stage"

wrangler secret put foo --env "stage"

wrangler secret put foo --env "stage" would make it available only to my

stage

stage

stage

stage env, as created in my TOML?

Re-deploying seems to have fixed it. But: Something must have happened on 2023-12-24 that caused the

Similar Threads

Similar Threads

Similar Threads