Allow specifying an environment to use variable from

[graygilmore]

Blocked

Currently based off of the work done here:

• Automatically inject variables in runtime #861

WHY are these changes introduced?

A follow up to both #861 and #809 that allows developers to specify which environment to use.

When these commands were first added/updated we defaulted to always pulling the Preview environment variables but there are cases where developers may want to use a different environment for testing purposes.

WHAT is this pull request doing?

We recently shipped the ability to specify a branchName argument in the Admin API for the environmentVariables field. This PR hooks into that field and adds a new flag to commonFlags to facilitate it.

HOW to test your changes?

1. Pull the branch and navigate to the cli directory
2. Run npm run build
3. Navigate to the demo store directory cd ../../templates/demo-store
4. Run h2 env pull --branch <BRANCH> (note: if h2 is unavailable run npx shopify hydrogen shortcut first) to pull your specified environment variables down
   • You should be prompted to provide a shop
   • You should then be prompted to authenticate with that shop
   • You should be prompted that you need to link to a storefront
   • Note: replace <BRANCH> with the branch associated to an environment on your linked shop (e.g. main for most Production environments)
5. Confirm that the variables pulled are from your specified branch's environment

Checklist

• I've read the Contributing Guidelines
• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've added a changeset if this PR contains user-facing or noteworthy changes
• I've added tests to cover my changes
• I've added or updated the documentation

[frandiox]

Thanks! Maybe we should wrap the envPull call and improve error messages, since we know the response format:

For example, in the previous situation we could render a human readable "environment not found" error message and mention what they can try to fix the issue (use the "env list" command?).

---

Also, is "Preview" in the following correct? I think this is our Production branch.

[graygilmore]

Force Push Patch Notes

• Rebased with automatically-inject-variables since this PR is based on that work
  • Needed to make a small change now that combinedEnvironmentVariables is in a separate file

[graygilmore]

Force Push Patch Notes

• Renamed branch flag to env-branch
• Marked the flag as hidden
• Fixed a bug where we were still hardcoding Preview as the environment

[graygilmore]

Maybe we should wrap the envPull call and improve error messages, since we know the response format

I remember looking into this in my original exploration of these commands because we were thinking about returning custom error codes. Unfortunately (or fortunately depending on your perspective!) cli-kit captures the error and returns the output that you see in the screenshot. We'd have to overwrite how it does admin requests in order for us to capture the error and render it ourselves which I'd like to avoid doing. Let me know what you think!

[frandiox]

I remember looking into this in my original exploration of these commands because we were thinking about returning custom error codes. Unfortunately (or fortunately depending on your perspective!) cli-kit captures the error and returns the output that you see in the screenshot. We'd have to overwrite how it does admin requests in order for us to capture the error and render it ourselves which I'd like to avoid doing. Let me know what you think!

It looks like we can actually pass responseOptions: {handleErrors: false}, to graphqlRequest and wrap it in try/catch. This allows custom error handling on our end.

However, feel free to merge this without that change, it's something we can improve later 👍

[graygilmore]

Force Push Patch Notes

• Rebased with 2023-04 now that Automatically inject variables in runtime #861 has been merged