feat(ci): add reusable Cloudflare deploy workflow

[matheus1lva]

Summary

• add a reusable Cloudflare Worker deployment workflow alongside the Vercel workflow
• resolve CLOUDFLARE_API_TOKEN from the shared webops-prod-shared/CLOUDFLARE 1Password item
• resolve the target account ID and Worker secrets from the selected project vault
• upload Worker secrets with wrangler secret bulk, then deploy through the project's bun run deploy script
• document the caller contract and optional named Wrangler environment

Why

Cloudflare Worker projects need the same reusable, caller-scoped 1Password deployment pattern already available for Vercel projects, with the shared Cloudflare token kept in the shared vault.

Validation

• git diff --check
• go run github.com/rhysd/actionlint/cmd/actionlint@v1.7.7

[murderteeth]

before we review this and start reviewing cloudflare deploys, lets establish a spec like we did for vercel deploys, https://hackmd.io/@murderteeth/B1aFfRIXMx. then we can use the cloudflare spec while revieing this pr and our various cloudflare deployed projects.

[matheus1lva]

before we review this and start reviewing cloudflare deploys, lets establish a spec like we did for vercel deploys, hackmd.io/@murderteeth/B1aFfRIXMx. then we can use the cloudflare spec while revieing this pr and our various cloudflare deployed projects.

To me personally i see no difference at all, only vendor changing. The behavior, security guards we did to vercel only need to be translated to cloudflare. UNless im not picking up some slight nuance. Please make me aware!

Though if we want to use that as a paper checklist like:
"This service doesnt not follow this, lets migrate" - which i dont think its the expected output of this work.

[murderteeth]

before we review this and start reviewing cloudflare deploys, lets establish a spec like we did for vercel deploys, hackmd.io/@murderteeth/B1aFfRIXMx. then we can use the cloudflare spec while revieing this pr and our various cloudflare deployed projects.

To me personally i see no difference at all, only vendor changing. The behavior, security guards we did to vercel only need to be translated to cloudflare. UNless im not picking up some slight nuance. Please make me aware!

Though if we want to use that as a paper checklist like: "This service doesnt not follow this, lets migrate" - which i dont think its the expected output of this work.

when i review this work i want to use: /ship-spec https://github.com/yearn/yearn-gha/pull/2, must adhere to this spec https://hackmd.io/@murderteeth/B1aFfRIXMx -- otherwise we're reviewing each cicd in isolation when we have standards we want to enforce across them all. we dont have to use a spec, what do you suggest? otherwise maybe we should broaden the "Vercel Deployment Operating Guide" to just "Yearn Deployment Operating Guide" and it can include vercel, cf, etc.

[matheus1lva]

before we review this and start reviewing cloudflare deploys, lets establish a spec like we did for vercel deploys, hackmd.io/@murderteeth/B1aFfRIXMx. then we can use the cloudflare spec while revieing this pr and our various cloudflare deployed projects.

To me personally i see no difference at all, only vendor changing. The behavior, security guards we did to vercel only need to be translated to cloudflare. UNless im not picking up some slight nuance. Please make me aware!
Though if we want to use that as a paper checklist like: "This service doesnt not follow this, lets migrate" - which i dont think its the expected output of this work.

when i review this work i want to use: /ship-spec https://github.com/yearn/yearn-gha/pull/2, must adhere to this spec https://hackmd.io/@murderteeth/B1aFfRIXMx -- otherwise we're reviewing each cicd in isolation when we have standards we want to enforce across them all. we dont have to use a spec, what do you suggest? otherwise maybe we should broaden the "Vercel Deployment Operating Guide" to just "Yearn Deployment Operating Guide" and it can include vercel, cf, etc.

Oh ok valid point. But i also think the "operation guide" is a needed follow up (maybe on internal-docs? maybe in the gha repo? Possibly there)

[murderteeth]

before we review this and start reviewing cloudflare deploys, lets establish a spec like we did for vercel deploys, hackmd.io/@murderteeth/B1aFfRIXMx. then we can use the cloudflare spec while revieing this pr and our various cloudflare deployed projects.

To me personally i see no difference at all, only vendor changing. The behavior, security guards we did to vercel only need to be translated to cloudflare. UNless im not picking up some slight nuance. Please make me aware!
Though if we want to use that as a paper checklist like: "This service doesnt not follow this, lets migrate" - which i dont think its the expected output of this work.

when i review this work i want to use: /ship-spec https://github.com/yearn/yearn-gha/pull/2, must adhere to this spec https://hackmd.io/@murderteeth/B1aFfRIXMx -- otherwise we're reviewing each cicd in isolation when we have standards we want to enforce across them all. we dont have to use a spec, what do you suggest? otherwise maybe we should broaden the "Vercel Deployment Operating Guide" to just "Yearn Deployment Operating Guide" and it can include vercel, cf, etc.

Oh ok valid point. But i also think the "operation guide" is a needed follow up (maybe on internal-docs? maybe in the gha repo? Possibly there)

for now lets keep it in a public hackmd so it's easy to reference and link to. i think lets start a new one based on https://hackmd.io/@murderteeth/B1aFfRIXMx and go from there. lets figure out a permanent home later

[matheus1lva]

@murderteeth I've also added both to here despite, given it's easy to find and rarely goes away.

https://hackmd.io/@V3XqVsqGT2Wqs76oR-sw2A/S1XHZtSEMx - is the hackmd link.