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

Add cloudchamber curl command #6126

Merged
merged 4 commits into from
Sep 10, 2024
Merged

Conversation

IRCody
Copy link
Contributor

@IRCody IRCody commented Jun 22, 2024

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

  • Tests
    • TODO (before merge)
    • Included
    • Not necessary because:
  • E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)
    • I don't know
    • Required / Maybe required
    • Not required because: Cloudchamber has no e2e tests
  • Changeset (Changeset guidelines)
    • TODO (before merge)
    • Included
    • Not necessary because:
  • Public documentation
    • TODO (before merge)
    • Cloudflare docs PR(s):
    • Not necessary because: Cloudchamber is not documented externally

@IRCody IRCody requested review from a team as code owners June 22, 2024 00:07
Copy link

changeset-bot bot commented Jun 22, 2024

🦋 Changeset detected

Latest commit: 7386e8f

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

This PR includes changesets to release 2 packages
Name Type
wrangler Minor
@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

Copy link
Contributor

github-actions bot commented Jun 22, 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/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 with this latest build directly:

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.


wrangler@3.75.0 includes the following runtime dependencies:

Package Constraint Resolved
miniflare workspace:* 3.20240821.1
workerd 1.20240821.1 1.20240821.1
workerd --version 1.20240821.1 2024-08-21

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

@IRCody
Copy link
Contributor Author

IRCody commented Jun 28, 2024

The test failures seem to be coming from something unrelated to this change:

  
   FAIL  src/__tests__/sentry.test.ts > sentry > interactive > should hit sentry after reportable error when permission provided
  Error: Snapshot `sentry > interactive > should hit sentry after reportable error when permission provided 3` mismatched```

@threepointone threepointone force-pushed the cloudchamber-curl branch 5 times, most recently from c4745ed to c93e8aa Compare July 1, 2024 12:32
@threepointone
Copy link
Contributor

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.

@threepointone
Copy link
Contributor

I tried debugging, but it's a bit confusing, so I'm going to move away from this, cc @petebacondarwin

@IRCody
Copy link
Contributor Author

IRCody commented Jul 2, 2024

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.

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?

@IRCody
Copy link
Contributor Author

IRCody commented Jul 8, 2024

Rebased to try to keep this pr up to date. Still unsure what the issues are in CI.

@IRCody
Copy link
Contributor Author

IRCody commented Jul 12, 2024

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.

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?

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.

   FAIL  src/__tests__/cloudchamber/curl.test.ts > cloudchamber curl > should be able to use data flag
  Error: Snapshot `cloudchamber curl > should be able to use data flag 2` mismatched
  
  - Expected
  + Received
  
  - "{
  -     \"id\": \"1\",
  -     \"type\": \"default\",
  -     \"created_at\": \"123\",
  -     \"account_id\": \"123\",
  -     \"vcpu\": 4,
  -     \"memory\": \"400MB\",
  -     \"version\": 1,
  -     \"image\": \"hello\",
  -     \"location\": {
  -         \"name\": \"sfo06\",
  -         \"enabled\": true
  -     },
  -     \"network\": {
  -         \"ipv4\": \"1.1.1.1\"
  -     },
  -     \"placements_ref\": \"http://ref\",
  -     \"node_group\": \"metal\"
  - }"
  + "[object Object]"
  
   ❯ src/__tests__/cloudchamber/curl.test.ts:71:19
       69|   );
       70|   expect(std.err).toMatchInlineSnapshot(`""`);
       71|   expect(std.out).toMatchInlineSnapshot(`
         |                   ^
       72|    "{
       73|        \\"id\\": \\"1\\",
  

@IRCody IRCody force-pushed the cloudchamber-curl branch 3 times, most recently from 4a35958 to 8e24836 Compare July 12, 2024 22:31
@IRCody
Copy link
Contributor Author

IRCody commented Jul 12, 2024

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.

.changeset/new-dragons-bow.md Outdated Show resolved Hide resolved
packages/wrangler/src/__tests__/cloudchamber/curl.test.ts Outdated Show resolved Hide resolved
packages/wrangler/src/cloudchamber/curl.ts Show resolved Hide resolved
packages/wrangler/src/cloudchamber/index.ts Outdated Show resolved Hide resolved
@IRCody
Copy link
Contributor Author

IRCody commented Jul 26, 2024

@petebacondarwin: I tried to address all your points. Appreciate if you have time to take another look.

@IRCody IRCody added the awaiting Cloudflare response Awaiting response from workers-sdk maintainer team label Jul 29, 2024
@IRCody
Copy link
Contributor Author

IRCody commented Aug 2, 2024

@petebacondarwin: Thought I'd ping again to see if you have time to take another look.

Comment on lines +69 to +70
silent?: boolean;
verbose?: boolean;
Copy link
Contributor

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?

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 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?

Copy link
Contributor

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.

@IRCody
Copy link
Contributor Author

IRCody commented Aug 19, 2024

@petebacondarwin: Do the current changes look ok?

Copy link
Contributor

@petebacondarwin petebacondarwin left a 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.

.changeset/new-dragons-bow.md Outdated Show resolved Hide resolved
logRaw(
text
.split("\n")
.map((line) => `${yellow(`\t`)} ${brandColor(line)}`)
Copy link
Contributor

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?

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 also not sure what this .split/.map/.join is doing, since JSON.stringify(..., 4) already indents the output

Copy link
Contributor Author

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!

packages/wrangler/src/cloudchamber/curl.ts Outdated Show resolved Hide resolved
packages/wrangler/src/cloudchamber/curl.ts Outdated Show resolved Hide resolved
Comment on lines +69 to +70
silent?: boolean;
verbose?: boolean;
Copy link
Contributor

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.

@IRCody
Copy link
Contributor Author

IRCody commented Aug 22, 2024

Thanks for taking a look at this @RamIdeas!

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?

My expectation would be that output from this command that was being piped would use the json flag.

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.

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.
@RamIdeas
Copy link
Contributor

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?

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.

@IRCody
Copy link
Contributor Author

IRCody commented Sep 9, 2024

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?

@IRCody
Copy link
Contributor Author

IRCody commented Sep 9, 2024

@RamIdeas: Sorry I had to make a small additional change to make the type check happy.

@RamIdeas RamIdeas merged commit 18c105b into cloudflare:main Sep 10, 2024
18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting Cloudflare response Awaiting response from workers-sdk maintainer team
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

6 participants