Add cloudchamber curl command

[IRCody]

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)
  • [x] Included
  • [ ] Not necessary because:
• E2E Tests CI Job required? (Use "e2e" label or ask maintainer to run separately)
  • [x] I don't know
  • [ ] Required / Maybe required
  • [ ] Not required because:
• Changeset (Changeset guidelines)
  • [ ] TODO (before merge)
  • [x] Included
  • [ ] Not necessary because:
• Public documentation
  • [ ] TODO (before merge)
  • [ ] Cloudflare docs PR(s):
  • [x] Not necessary because: I don't believe any of the cloudchamber commands are documented there atm.

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 7386e8fbc35de144c4e9c377b883b6a523e4bbdb

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

[github-actions[bot]]

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.

---

[email protected] 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]

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]

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]

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

[IRCody]

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]

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

[IRCody]

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]

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.

[IRCody]

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

[IRCody]

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

[IRCody]

@petebacondarwin: Do the current changes look ok?

[IRCody]

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?

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

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]

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]

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