Skip to content
Adventive Adventive Engineering

Context

Workers Builds is GitHub and GitLab only. Bitbucket teams need an equivalent pipeline that lands on the same gate sequence, environments, and secrets model.

The constraint

Section titled “The constraint”

Cloudflare ships two ways to run CI/CD for Workers:

  1. Workers Builds, the native integrated system. It connects a Worker to a Git repository and builds and deploys on every push. Its Git integration supports GitHub and GitLab only.
  2. External CI/CD, where a pipeline you own runs Wrangler against a Cloudflare API token. Cloudflare documents this path for GitHub Actions and GitLab CI/CD, and explicitly recommends it for any Git provider that is not GitHub or GitLab.

Bitbucket is not a Workers Builds provider. Cloudflare’s own guidance routes Bitbucket users to external CI/CD. There is no dashboard “connect repository” flow for Bitbucket, and there is no roadmap commitment to add one. Any Bitbucket pipeline therefore lives on the Bitbucket side and calls Wrangler to upload and deploy.

Who this affects

Section titled “Who this affects”

Part of the engineering organization keeps Bitbucket as the primary code repository. Those teams building Workers cannot adopt Workers Builds. They need a pipeline that produces the same outcome: a push builds, tests, and deploys a Worker, with production gated behind review.

Teams already on GitHub continue to use Workers Builds or the GitHub Actions stub in the Workers SOP. This project does not change their flow.

What stays the same across providers

Section titled “What stays the same across providers”

The provider changes. The platform contract does not. Regardless of where the source lives, every Worker deploy honors:

  • The gate sequence from the QA and Deployment SOP: install, lint, typecheck, unit tests, secret scan, dry-run deploy, then deploy and smoke test.
  • The three environments dev, stg, prd, mapped to the adventive.dev, adventivestg.com, and adventive.com zones.
  • The staging soak window before any promotion to production, sized by change type and Worker tier.
  • The secrets model: runtime secrets come from Cloudflare Secrets Store, bound by reference in wrangler.toml. The only credentials the pipeline holds are a scoped Cloudflare API token and the account ID.
  • Instant rollback via wrangler rollback as the containment action when a deploy goes wrong.

A Bitbucket pipeline is a re-expression of the existing GitHub Actions model in Bitbucket’s YAML. It is not a new deployment philosophy.

Reconciliation note

Section titled “Reconciliation note”

The team contract (CLAUDE.md §3.2) currently reads “deploys never run from GitHub Actions.” The QA and Deployment SOP and the worker-stub/.github/workflows/ci.yml both deploy from CI. Per the repo’s own precedence rule (docs win over CLAUDE.md), the CI-driven model is authoritative. This proposal follows the SOP. The CLAUDE.md wording is logged for reconciliation in FOLLOW_UPS.md.