Skip to content
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

Workflows open beta warning on deploy #7068

Merged
merged 4 commits into from
Oct 23, 2024
Merged

Conversation

RamIdeas
Copy link
Contributor

Supersedes #7047

Fixes #7047

Adds a warning reminding the user that Workflows is in open beta – if their config file contains any workflows – in wrangler deploy, wrangler versions upload, wrangler versions deploy and wrangler trigger deploy.


  • Tests
    • TODO (before merge)
    • Tests included
    • Tests not necessary because:
  • E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)
    • I don't know
    • Required
    • Not required because: covered by other tests
  • Public documentation
    • TODO (before merge)
    • Cloudflare docs PR(s):
    • Documentation not necessary because: already documented

@RamIdeas RamIdeas requested a review from a team as a code owner October 23, 2024 11:42
Copy link

changeset-bot bot commented Oct 23, 2024

🦋 Changeset detected

Latest commit: b0e01e4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages
Name Type
wrangler Patch
@cloudflare/vitest-pool-workers Patch

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


return (...args: Parameters<typeof console.warn>) => {
if (!logged) {
console.warn(...args);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This previously used console.warn instead of logger.warn

This helper has been replaced by logger.warnOnce which will use logger.warn

Copy link
Contributor

github-actions bot commented Oct 23, 2024

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/11479645360/npm-package-wrangler-7068

You can reference the automatically updated head of this PR with:

npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/7068/npm-package-wrangler-7068

Or you can use npx with this latest build directly:

npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11479645360/npm-package-wrangler-7068 dev path/to/script.js
Additional artifacts:
npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11479645360/npm-package-create-cloudflare-7068 --no-auto-update
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11479645360/npm-package-cloudflare-kv-asset-handler-7068
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11479645360/npm-package-miniflare-7068
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11479645360/npm-package-cloudflare-pages-shared-7068
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11479645360/npm-package-cloudflare-vitest-pool-workers-7068
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11479645360/npm-package-cloudflare-workers-editor-shared-7068
npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/11479645360/npm-package-cloudflare-workers-shared-7068

Note that these links will no longer work once the GitHub Actions artifact expires.


wrangler@3.82.0 includes the following runtime dependencies:

Package Constraint Resolved
miniflare workspace:* 3.20241018.0
workerd 1.20241022.0 1.20241022.0
workerd --version 1.20241022.0 2024-10-22

Please ensure constraints are pinned, and miniflare/workerd minor versions match.

Comment on lines -192 to +198
"Unrecognised WRANGLER_LOG value \\"everything\\", expected \\"none\\" | \\"error\\" | \\"warn\\" | \\"info\\" | \\"log\\" | \\"debug\\", defaulting to \\"log\\"...
▲ [WARNING] This is a warn message
"▲ [WARNING] Unrecognised WRANGLER_LOG value \\"everything\\", expected \\"none\\" | \\"error\\" | \\"warn\\" | \\"info\\" | \\"log\\" | \\"debug\\", defaulting to \\"log\\"...

"
`);

▲ [WARNING] This is a warn message

"
`);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was previously using console.warn. Now using logger.warn prepends the ansi colourised "[WARNING]"

@@ -51,7 +40,7 @@ function getLoggerLevel(): LoggerLevel {
const expected = Object.keys(LOGGER_LEVELS)
.map((level) => `"${level}"`)
.join(" | ");
warnOnce(
logger.warnOnce(
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure we should be using logger methods inside getLoggerLevel() like this—it feels like a bit of a circular dependency

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I thought that may have been the reason. But this function is about to override the default log level – since the default log level will not swallow warnings, I think it's okay to use logger.warn

Copy link
Contributor

Choose a reason for hiding this comment

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

Is it not going to be slightly circular though? logger.warnOnce() will eventually call getLoggerLevel() which will then call logger.warnOnce() again and so on. I might be misunderstanding, but that would be my expectation

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah I guess. But luckily logger.warnOnce only calls logger.warn... once 😉

@@ -118,6 +107,17 @@ export class Logger {
Logger.#afterLogHook?.();
}

static warnOnceHistory = new Set();
Copy link
Contributor

@penalosa penalosa Oct 23, 2024

Choose a reason for hiding this comment

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

Why is this static? It feels like each logger instance should have it's own warnOnce set

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If a subclass wants a new set, it can override its own static property i.e. static warnOnceHistory = new Set() on the class

I guess if it was an instance property, the inverse could also be said: If a subclass wants to share the set, it can override its own instance property i.e. this.warnOnceHistory = logger.warnOnceHistory in the constructor

The former seems simpler but not tied to either tbh

Copy link
Contributor

Choose a reason for hiding this comment

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

A subclass can, but multiple instances of the Logger class can't, AFAIK? That seems like the problem to me here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah sorry you said instance not subclass

The logger is currently a singleton so I'm more concerned with subclasses (we do this with Miniflare's Log class to intercept method calls, where we would expect this kind of property to be shared).

From this feature's perspective, I'd want these warnings to be logged once per invocation of wrangler not per instance of the logger

Copy link
Contributor

Choose a reason for hiding this comment

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

The logger is used as a singleton in Wrangler, but there's no inherit reason it has to be, and in various tests we construct multiple instances. It seems to me that it would be kinda strange for those instances to share this warnOnce set.

In terms of subclasses, maybe we're coming at this from different angles, but I would be really surprised if a method call on an instance of the parent class affected method calls on an instance of a subclass.

Copy link
Contributor

@penalosa penalosa left a comment

Choose a reason for hiding this comment

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

Not going to block on the logger changes—we can land as-is and followup. In general:

  • I don't think we should be using a mutable static property for this—this feels to me like it should be an instance property that is not shared to subclasses unless specifically set up in the constructor
  • I think we should be using console.warn() in getLoggerLevel() to avoid the circular dependency (I realise it's avoided by the "once" nature of warnOnce() when it's called the second time, but it still feels unnecessarily circular)

@RamIdeas RamIdeas merged commit a2afcf1 into main Oct 23, 2024
20 checks passed
@RamIdeas RamIdeas deleted the workflows-deploy-warning branch October 23, 2024 12:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants