Skip to content

Deploy integration builds to production Worker#72

Merged
Just-Insane merged 3 commits into
integrationfrom
codex/fast-moving-worker-deploy
Jun 14, 2026
Merged

Deploy integration builds to production Worker#72
Just-Insane merged 3 commits into
integrationfrom
codex/fast-moving-worker-deploy

Conversation

@Just-Insane

@Just-Insane Just-Insane commented Jun 14, 2026

Copy link
Copy Markdown
Collaborator

Description

Deploys integration builds directly to the production Cloudflare Worker for the current fast-moving hosting setup, while keeping the tag/manual OpenTofu path documented for a future stable release cadence.

This updates the integration deploy workflow from preview-version upload to wrangler deploy, points the OpenTofu custom-domain default at charm.cloudhub.social, enables Worker observability/persisted invocation logs, removes the deprecated custom-domain environment setting, and adds Cloudflare static asset headers for cache behavior and Sentry browser profiling.

Pre-PR research: searched CloudHub-Social/Charm PRs and issues for Cloudflare, Wrangler, OpenTofu, deploy, and charm.cloudhub.social. No related issues were found; nearby PR history was general repo/release/dependency work rather than an overlapping deployment change.

Production deployment variable updated outside this PR: the GitHub production environment CLIENT_CONFIG_OVERRIDES_JSON now matches the CloudHub config for element call, push, session sync, sliding sync, polls, and featured community servers. Sentry DSN remains a GitHub secret consumed by the workflow.

Fixes #

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings

AI disclosure:

  • Partially AI assisted (clarify which code was AI assisted and briefly explain what it does).
  • Fully AI generated (explain what all the generated code does in moderate detail).

This PR was generated by Codex. It changes the GitHub Actions integration deployment from uploading an aliased Worker preview version to deploying the built Worker to production with wrangler deploy, updates the OpenTofu custom-domain default for the Worker to charm.cloudhub.social, enables Cloudflare Worker observability, removes a deprecated OpenTofu provider attribute, records the provider checksum needed for local OpenTofu validation, adds Cloudflare _headers for static asset caching and JS profiling, adds a patch changeset, and updates the infrastructure documentation to describe both the fast-moving production path and the stable tag/manual fallback.

Validation:

  • tofu -chdir=infra/web fmt -check
  • TF_DATA_DIR=$(mktemp -d) tofu -chdir=infra/web init -backend=false -input=false && TF_DATA_DIR=$TF_DATA_DIR tofu -chdir=infra/web validate -no-color
  • pnpm typecheck
  • pnpm build
  • test -f dist/_headers
  • jq '.observability, .assets, .name' dist/wrangler.json
  • pnpm exec wrangler deploy -c dist/wrangler.json --keep-vars --message dry-run --dry-run
  • pnpm exec oxfmt --check .github/workflows/cloudflare-dev-deploy.yml .github/workflows/cloudflare-web-preview.yml infra/README.md infra/web/main.tf vite.config.ts public/_headers .changeset/fast-moving-worker-production-deploy.md
  • workflow YAML parse check
  • git diff --check

@github-actions

github-actions Bot commented Jun 14, 2026

Copy link
Copy Markdown

OpenTofu plan for production

Plan: 4 to add, 0 to change, 0 to destroy. Changes to Outputs.
OpenTofu used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
+   create

OpenTofu will perform the following actions:

  # cloudflare_worker.site will be created
+   resource "cloudflare_worker" "site" {
+       account_id     = (sensitive value)
+       created_on     = (known after apply)
+       id             = (known after apply)
+       logpush        = false
+       name           = "charm"
+       observability  = {
+           enabled            = true
+           head_sampling_rate = 1
+           logs               = {
+               enabled            = true
+               head_sampling_rate = 1
+               invocation_logs    = true
            }
        }
+       references     = (known after apply)
+       subdomain      = {
+           enabled          = true
+           previews_enabled = true
        }
+       tags           = []
+       tail_consumers = []
+       updated_on     = (known after apply)
    }

  # cloudflare_worker_version.site will be created
+   resource "cloudflare_worker_version" "site" {
+       account_id          = (sensitive value)
+       annotations         = (known after apply)
+       assets              = {
+           asset_manifest_sha256 = "47085533747b4a6c9cc32a0bf85f011ea7df0d5df710db5c60c24d1dba0ae8e7"
+           config                = {
+               not_found_handling = "single-page-application"
            }
+           directory             = "/github/workspace/dist"
        }
+       compatibility_date  = "2026-03-03"
+       compatibility_flags = (known after apply)
+       created_on          = (known after apply)
+       id                  = (known after apply)
+       limits              = (known after apply)
+       main_script_base64  = (known after apply)
+       number              = (known after apply)
+       source              = (known after apply)
+       startup_time_ms     = (known after apply)
+       usage_model         = "standard"
+       worker_id           = (known after apply)
    }

  # cloudflare_workers_custom_domain.site will be created
+   resource "cloudflare_workers_custom_domain" "site" {
+       account_id = (sensitive value)
+       hostname   = "charm.cloudhub.social"
+       id         = (known after apply)
+       service    = "charm"
+       zone_id    = (sensitive value)
+       zone_name  = (known after apply)
    }

  # cloudflare_workers_deployment.site will be created
+   resource "cloudflare_workers_deployment" "site" {
+       account_id   = (sensitive value)
+       annotations  = {
+           workers_message      = "Deploy integration builds to production Worker"
+           workers_triggered_by = (known after apply)
        }
+       author_email = (known after apply)
+       created_on   = (known after apply)
+       id           = (known after apply)
+       script_name  = "charm"
+       source       = (known after apply)
+       strategy     = "percentage"
+       versions     = [
+           {
+               percentage = 100
+               version_id = (known after apply)
            },
        ]
    }

Plan: 4 to add, 0 to change, 0 to destroy.

Changes to Outputs:
!~  custom_domain = "dev.cloudhub.social" -> "charm.cloudhub.social"

Warning: Resource not found

  with cloudflare_worker.site,
  on main.tf line 1, in resource "cloudflare_worker" "site":
   1: resource "cloudflare_worker" "site" {

The resource was not found on the server and will be removed from state.

📝 Plan generated in Cloudflare Infra #207

@github-code-quality

github-code-quality Bot commented Jun 14, 2026

Copy link
Copy Markdown

Code Coverage Overview

Languages: JavaScript

JavaScript / code-coverage/vitest

The overall coverage remains at 21%, unchanged from the branch.


Updated June 14, 2026 18:59 UTC
Code Coverage is in Public Preview. Learn more and provide us with your feedback.

@Just-Insane Just-Insane marked this pull request as ready for review June 14, 2026 18:44
@github-actions

Copy link
Copy Markdown

Deploying with  Cloudflare Workers  Cloudflare Workers

Status Preview URL Commit Alias Updated (UTC)
✅ Deployment successful! https://pr-72-charm.justin-tech.workers.dev f293bf8 pr-72 Sun, 14 Jun 2026 18:58:34 GMT

@Just-Insane Just-Insane merged commit fe6c02c into integration Jun 14, 2026
15 of 16 checks passed
@Just-Insane Just-Insane deleted the codex/fast-moving-worker-deploy branch June 14, 2026 18:59

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 730599acb7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +79 to +82
deploy
-c dist/wrangler.json
--preview-alias integration
--message "$PREVIEW_MESSAGE"
--keep-vars
--message "$DEPLOY_MESSAGE"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Include all build inputs in the production trigger

Now that this job performs the production deploy, keeping the old path filter means production is skipped for build inputs that are not listed there. I checked vite.config.ts and the build copies public/manifest.json, public/res, and public/locales into dist, and setup installs from pnpm-lock.yaml; pushes to integration that only change those files do not match this workflow's paths, so wrangler deploy never runs and charm.cloudhub.social keeps serving the previous build. Please include the missing build inputs or remove the path filter for this production deploy.

Useful? React with 👍 / 👎.

Comment on lines +79 to +82
deploy
-c dist/wrangler.json
--preview-alias integration
--message "$PREVIEW_MESSAGE"
--keep-vars
--message "$DEPLOY_MESSAGE"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Retain old Worker assets during deploys

For users who already loaded HTML or a service worker that references the previous hashed Vite chunks, this production deploy deletes replaced Worker assets immediately, so a lazy chunk or asset requested just after an integration deploy can 404 until the app recovers with a reload. I checked pnpm exec wrangler deploy --help, which documents --old-asset-ttl as expiring old assets after the given seconds "rather than immediate deletion"; add a nonzero TTL to this new production deploy path so fast-moving integration pushes do not strand in-flight clients.

Useful? React with 👍 / 👎.

accountId: ${{ secrets.TF_VAR_ACCOUNT_ID }}
command: >
versions upload
deploy

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Serialize production Worker deploys

When a tag or manual release deploy is running, this new production wrangler deploy can run at the same time because I checked .github/workflows/cloudflare-web-deploy.yml and it uses the separate cloudflare-infra concurrency group. Both workflows now promote the same charm Worker, so an integration push during a release can overwrite it (or be overwritten) depending only on which job finishes last; put both production paths in the same concurrency group or otherwise gate one while the other is active.

Useful? React with 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant