-
Notifications
You must be signed in to change notification settings - Fork 302
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
CLI: 'env' command moved to 'env dump' subcommand #1920
Conversation
This makes room for other future subcommands that relate to environment.
main.go
Outdated
{ | ||
Name: "env", | ||
Usage: "Something something environment variables", | ||
Subcommands: []cli.Command{ | ||
clicommand.EnvDumpCommand, | ||
}, | ||
}, |
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.
{ | |
Name: "env", | |
Usage: "Something something environment variables", | |
Subcommands: []cli.Command{ | |
clicommand.EnvDumpCommand, | |
}, | |
}, | |
{ | |
Name: "env", | |
Usage: "Something something environment variables", | |
Subcommands: []cli.Command{ | |
clicommand.EnvDumpCommand, | |
}, | |
Action: clicommand.EnvDumpAction, | |
}, |
I think something like this (with appropriate changes in clicommand/env_dump.go
) should work to allow buildkite-agent env
and buildkite-agent env dump
to be synonymous.
Not only does it preserve backward compatibility (up to the flag changes you made), but I actually think this is desirable behaviour in the long term.
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.
but I actually think this is desirable behaviour in the long term
I wonder. I don't think dumping the process' current env is very useful outside the one weird use-case we have internally, which we hope to eliminate via control sockets. I can't imagine a user actually wanting to use buildkite-agent env
to see their environment as JSON. I'd rather it show the usage and list of subcommands.
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.
If we're making what is technically a breaking change, you'd appreciate if it went out as soon as possible (in the next release)?
Yeah I guess the sooner the better, but not urgent if we feel it needs more discussion. |
Thanks — I was just looking into that, and now I don't have to finish doing that :) |
It feels strange to be able to do that 😅 |
This makes room for other future subcommands that relate to environment. Co-authored-by: Josh Deprez <[email protected]>
Move the
buildkite-agent env
command (which dumps environment to stdout) tobuildkite-agent env dump
, makingbuildkite-agent env
just a container for this and any future subcommands relating to environment.As suggested by @sj26 in October: #1803 (comment)
More recently the idea of a
buildkite-agent env set <key> <value>
command came up in Re: 💡 Agent sockets - Pipelines Dispatch ⚙️It's relatively safe to assume that the only usage of the existing
buildkite-agent env
command is by the agent itself, making it essentially a private/internal API which we can safely change.