-
Notifications
You must be signed in to change notification settings - Fork 688
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
Add cloudchamber curl command #6126
Conversation
🦋 Changeset detectedLatest commit: 7386e8f 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 |
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/10781169193/npm-package-wrangler-6126 You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/6126/npm-package-wrangler-6126 Or you can use npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10781169193/npm-package-wrangler-6126 dev path/to/script.js Additional artifacts:npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10781169193/npm-package-create-cloudflare-6126 --no-auto-update npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10781169193/npm-package-cloudflare-kv-asset-handler-6126 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10781169193/npm-package-miniflare-6126 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10781169193/npm-package-cloudflare-pages-shared-6126 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10781169193/npm-package-cloudflare-vitest-pool-workers-6126 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10781169193/npm-package-cloudflare-workers-editor-shared-6126 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/10781169193/npm-package-cloudflare-workers-shared-6126 Note that these links will no longer work once the GitHub Actions artifact expires.
Please ensure constraints are pinned, and |
b36cb7f
to
01aa49c
Compare
The test failures seem to be coming from something unrelated to this change:
|
c4745ed
to
c93e8aa
Compare
as you can tell, I've been poking at this PR. Looks like there's an actual failure on windows. I don't have a windows machine, so I'm debugging with CI. I'll keep poking at it. |
c93e8aa
to
26f906f
Compare
I tried debugging, but it's a bit confusing, so I'm going to move away from this, cc @petebacondarwin |
I don't see the windows error in the current test failures. I also do not have a windows machine to test on. What errors were showing up there? |
Rebased to try to keep this pr up to date. Still unsure what the issues are in CI. |
45c12e8
to
7c8146e
Compare
Now that I'm in the org and can re-run the tests I can see this failure at least. Still investigating why it's happening and what would be different on windows specifically here as this passes on ubuntu/mac.
|
4a35958
to
8e24836
Compare
The issue with the windows tests was differences in escaping. Fixed by using JSON.stringify so we get the correct escaping for whatever platform the tests are run on. |
8e24836
to
bfc5016
Compare
@petebacondarwin: I tried to address all your points. Appreciate if you have time to take another look. |
bfc5016
to
efa2c8d
Compare
@petebacondarwin: Thought I'd ping again to see if you have time to take another look. |
silent?: boolean; | ||
verbose?: boolean; |
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.
Do these have meaning over and above the WRANGLER_LOG
env var that can control what logger
methods actually write to the console?
Is there a reason you are not using 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.
I thought that users might want to have different output preferences for curl specifically than most other commands but I agree it's a little inconsistent and potentially confusing.
Do you think it would make sense to change this to if the user requests a json response we print out in the current way but otherwise we use the logger and respect WRANGLER_LOG?
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 think we'd need to be careful with the output here. Is it expected that this command's output will be piped to other processes? If so, would changes to the output be considered a breaking change?
Since we've provided a --json flag, we should guide scripting users to that terse output which will reflect the backcompat of the api being hit. Leaving us more free to iterate on the human-readable output without fear of breaking anyone's workflow.
I don't see a problem with the --verbose
flag, since WRANGLER_LOG
or --log-level
don't have a concept of verbosity, only debug logging. My only issue is if it encourages users to script against stdout, preventing us from iterating on this command.
@petebacondarwin: Do the current changes look ok? |
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.
LGTM - might be worth getting second set of eyes from @RamIdeas, since he is interested in how we do CLI input and output and JSON etc.
logRaw( | ||
text | ||
.split("\n") | ||
.map((line) => `${yellow(`\t`)} ${brandColor(line)}`) |
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 there a need for \t
to be yellow?
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 also not sure what this .split/.map/.join is doing, since JSON.stringify(..., 4) already indents the output
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 split/map/join is just adding the color.
Is there a need for
\t
to be yellow?
The \t doesn't need to be there at all actually, thanks!
silent?: boolean; | ||
verbose?: boolean; |
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 think we'd need to be careful with the output here. Is it expected that this command's output will be piped to other processes? If so, would changes to the output be considered a breaking change?
Since we've provided a --json flag, we should guide scripting users to that terse output which will reflect the backcompat of the api being hit. Leaving us more free to iterate on the human-readable output without fear of breaking anyone's workflow.
I don't see a problem with the --verbose
flag, since WRANGLER_LOG
or --log-level
don't have a concept of verbosity, only debug logging. My only issue is if it encourages users to script against stdout, preventing us from iterating on this command.
Thanks for taking a look at this @RamIdeas!
My expectation would be that output from this command that was being piped would use the json flag.
Do you think it would make sense to make json output the default as a way to steer people towards it and instead have a --human flag or something for human readable text? |
Switch to using formatLabelledValues from utils. Remove some unneeded conditions in an else block.
I think we should remain consistent with a --json flag that defaults to false. I think we should call it out in the --json flag description that it is should be used if the output is being piped. Are there docs for this command? Maybe also call it out there. |
Sorry for the delay here. I added some text to the json flag description about using it for consistent, machine readable output. Does this match what you were looking for? |
2d126cd
to
7386e8f
Compare
@RamIdeas: Sorry I had to make a small additional change to make the type check happy. |
What this PR solves / how to test
Adds a cloudchamber curl command. Example usage:
wrangler cloudchamber curl /ssh-public-keys
CC-3877
Author has addressed the following