Align secrets env command with design in documentation

[tegefaulkes]

Description

This PR brings the secrets env command in line with how it is described in the documentation.

Issues Fixed

• Fixes Polykey-Docs:polykey secrets env command doesn't align with Development Environment Secrets how-to-guide #176
• REF ENG-302

Tasks

• 1. For unix systems, outputting the result to stdout should be using ' single quotes, not " double quotes.
• 2. You should not bother with comments like # my-software-project:AWS_SECRET_ACCESS_KEY. We don't really want to show this information.
• 3. The EOL at the end of showing secrets env IS CORRECT. It is not a bug. That's how env regularly works. You should have tests that ensure no regression on this.
• 5. The help text IS TOO LONG when you do polykey secrets --help. It should be a single line in that scenario.
• 6. The usage of --env to specify the secrets you want to put into the vault is not the requirement. See the original design here: https://polykey.com/docs/how-to-guides/developers/development-environment-secrets.
• 7. The command and arguments help is wrong it shows up as when running polykey secrets env --help: cmd] [argv command and arguments`

Final checklist

• Domain specific tests
• Full tests
• Updated inline-comment documentation
• Lint fixed
• Squash and rebased
• Sanity check the final build

[linear]

ENG-302 Polykey-Docs:`polykey secrets env` command doesn't align with Development Environment Secrets how-to-guide

[CMCDragonkai]

Did you read the docs page for this? What was written above may not be entirely matching it. Best to re-review that docs page.

[tegefaulkes]

I had a look and I'm trying to align with it. That said, it mentions an -e flag and I'm very unclear what that's for. It says # use the -e flag to export all variables which doesn't match any behaviour we've discussed.

[CMCDragonkai]

Where does it say this?

[tegefaulkes]

Towards the bottom of the https://polykey.com/docs/how-to-guides/developers/development-environment-secrets docs.

[tegefaulkes]

Rather than specifying -e <secretPath> as a required option. You provide the secretPaths as part of the main argument now. The format for this is [secretPaths...][cmdArgs...]. So we provide secrets env vault:path command arg1 arg2. The parser expects the secret paths first. Any argument that doesn't match the secret path will be taken as part of the command args. All args are taken as command args after the first non secret path arg.

[CMCDragonkai]

Hmm well I think it's possible I might have tried to get -e to mean all variables even subdir. But actually perhaps it is not needed and globbing can be used. Like * or **. I would use a git based globbing interpretation. So this might need to be applied to the EFS. Have a look at how to process globs.

[tegefaulkes]

Also in the docs, the following doesn't align with how we create secrets.

# using the argument style, note that we add 1 space ahead of the command ensure CLI history is not tracking this command
 pk secrets put my-software-project:AWS_ACCESS_KEY_ID '****'

# using the prompt style, finish the message by sending EOF <CTRL> + <D>
pk secrets put my-software-project:GOOGLE_MAPS_API_KEY
> '****'

# using the file descriptor style
pk secrets put my-software-project:PG_PASSWORD -f ./pg_password_data
# ... now add in all the other secrets

We use secrets create to create secrets. You can only do that by specifying a file that is already created, like in the 3rd example. The 1st example seems problematic since it would leak the secret to the process list. The 2nd would be nice to have though. Do we want to rewrite secrets create functionality while we're at it?