-
Notifications
You must be signed in to change notification settings - Fork 710
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Separate config for workers_dev_previews #7227
base: main
Are you sure you want to change the base?
Conversation
Many tests had mocks that weren't called, or had false assertions about not updating subdomain routes when they actually were being updated. Additionally, available_on_subdomain is now unecessary during script-upload, as it is not read there, due to being handled entirely within triggers-deploy. This also saves a double call to get /subdomain in the new-api path. The get/update subdomain helpers are refactored from deploy/version tests, and unified to standardize default workername and legacyEnv. I wanted to remove the getSubdomain mock from mockUpload entirely, but there were a bit too many callsites... At least every test now that makes assertions about workers.dev deployments does explicitly reset the mock return value.
🦋 Changeset detectedLatest commit: 40665e2 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
}); | ||
} | ||
if (!deployToWorkersDev && deploymentInSync && routes.length !== 0) { | ||
// TODO is this true? How does last subdomain status affect route confict?? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I kept this unchanged (aside from unrolling the conditional branches for easier context readability), but I don't think this branch makes sense anymore.
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11785260416/npm-package-wrangler-7227 You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/7227/npm-package-wrangler-7227 Or you can use npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11785260416/npm-package-wrangler-7227 dev path/to/script.js Additional artifacts:npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11785260416/npm-package-create-cloudflare-7227 --no-auto-update npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11785260416/npm-package-cloudflare-kv-asset-handler-7227 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11785260416/npm-package-miniflare-7227 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11785260416/npm-package-cloudflare-pages-shared-7227 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11785260416/npm-package-cloudflare-vitest-pool-workers-7227 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11785260416/npm-package-cloudflare-workers-editor-shared-7227 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11785260416/npm-package-cloudflare-workers-shared-7227 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11785260416/npm-package-cloudflare-workflows-shared-7227 Note that these links will no longer work once the GitHub Actions artifact expires.
Please ensure constraints are pinned, and |
Sorry to bikeshed on this, but I'm not sure about the name here. I know previews are always on |
The current Preview URLs (beta) feature routes to version preview urls based on the status of the `workers_dev` config value. Beta users have requested the ability to enable deployment urls and preview urls separately on `workers.dev`, and the new `previews_enabled` field of the enable-subdomain API will allow that. This change separates the `workers_dev` and `workers_dev_previews` behavior during `wrangler triggers deploy` and `wrangler versions upload`. `wrangler_dev_previews` defaults to true, and does not implicitly depend on routes the way `wrangler_dev` does.
6ca4cbf
to
40665e2
Compare
headers: { | ||
"Content-Type": "application/json", | ||
}, | ||
}) | ||
.then(() => [scriptURL]) | ||
.then(() => [deploymentURL]) | ||
// Add a delay when the subdomain is first created. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Incidentally, we should probably remove this. Avoiding negative dns cache is important during the first ~30 seconds of subdomain registration, but is not relevant when enabling the subdomain route of a particular Worker.
Definitely open to change! Any of |
After a quick chat with everyone, we decided |
Fixes WC-2914
Add
workers_dev_previews
toggle towrangler.toml
The current Preview URLs (beta) feature routes to version preview urls based on the status of the
workers_dev
config value. Beta users have requested the ability to enable deployment urls and preview urls separately onworkers.dev
, and the newpreviews_enabled
field of the enable-subdomain API will allow that. This change separates theworkers_dev
andworkers_dev_previews
behavior duringwrangler triggers deploy
andwrangler versions upload
.wrangler_dev_previews
defaults to true, and does not implicitly depend on routes the waywrangler_dev
does.TODO
blocked on API release
Tests
E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)
Public documentation