-
Notifications
You must be signed in to change notification settings - Fork 697
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
Conversation
🦋 Changeset detectedLatest commit: b0e01e4 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 |
|
||
return (...args: Parameters<typeof console.warn>) => { | ||
if (!logged) { | ||
console.warn(...args); |
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.
This previously used console.warn instead of logger.warn
This helper has been replaced by logger.warnOnce which will use logger.warn
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 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.
Please ensure constraints are pinned, and |
"Unrecognised WRANGLER_LOG value \\"everything\\", expected \\"none\\" | \\"error\\" | \\"warn\\" | \\"info\\" | \\"log\\" | \\"debug\\", defaulting to \\"log\\"... | ||
[33m▲ [43;33m[[43;30mWARNING[43;33m][0m [1mThis is a warn message[0m | ||
"[33m▲ [43;33m[[43;30mWARNING[43;33m][0m [1mUnrecognised WRANGLER_LOG value \\"everything\\", expected \\"none\\" | \\"error\\" | \\"warn\\" | \\"info\\" | \\"log\\" | \\"debug\\", defaulting to \\"log\\"...[0m | ||
|
||
" | ||
`); | ||
|
||
[33m▲ [43;33m[[43;30mWARNING[43;33m][0m [1mThis is a warn message[0m | ||
|
||
" | ||
`); |
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.
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( |
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'm not sure we should be using logger
methods inside getLoggerLevel()
like this—it feels like a bit of a circular dependency
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 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
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.
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
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.
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(); |
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.
Why is this static? It feels like each logger instance should have it's own warnOnce set
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.
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
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.
A subclass can, but multiple instances of the Logger class can't, AFAIK? That seems like the problem to me here
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.
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
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.
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.
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.
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()
ingetLoggerLevel()
to avoid the circular dependency (I realise it's avoided by the "once" nature ofwarnOnce()
when it's called the second time, but it still feels unnecessarily circular)
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
andwrangler trigger deploy
.