-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
tbot configure
command for assisting Machine ID configuration
#12517
tbot configure
command for assisting Machine ID configuration
#12517
Conversation
7d57aa0
to
7df8370
Compare
// the same across dev laptops and GCB. | ||
// If we switch to a more dependency injected model for botfs, we can | ||
// ensure that the test one returns the same value across operating systems. | ||
normalizeOSDependentValues := func(data []byte) []byte { |
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.
I'm really not a fan of this, but I didn't want to completely refactor botfs
to be a dependency injected struct without a bit more investigation.
I'm completely open to some more suggestions here.
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.
Yeah, that's unfortunate. The overly-simple botfs design has caused some problems already and I'm not opposed to refactoring it.
116b026
to
f26dd16
Compare
fdde9b1
to
2ef34cd
Compare
f8b5bad
to
3cda886
Compare
// the same across dev laptops and GCB. | ||
// If we switch to a more dependency injected model for botfs, we can | ||
// ensure that the test one returns the same value across operating systems. | ||
normalizeOSDependentValues := func(data []byte) []byte { |
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.
Yeah, that's unfortunate. The overly-simple botfs design has caused some problems already and I'm not opposed to refactoring it.
@@ -292,7 +296,7 @@ func FromCLIConf(cf *CLIConf) (*BotConfig, error) { | |||
} | |||
|
|||
if err := config.CheckAndSetDefaults(); err != nil { | |||
return nil, trace.Wrap(err, "validing merged bot config") | |||
return nil, trace.Wrap(err, "validating merged bot config") |
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.
🤦
3cda886
to
2f39587
Compare
2f39587
to
77dba07
Compare
77dba07
to
93a4214
Compare
* add `tbot configure` command * introduce golden file test helper * address PR comments by zmb
* add `tbot configure` command * introduce golden file test helper * address PR comments by zmb
…) (#12576) * add `tbot configure` command * introduce golden file test helper * address PR comments by zmb
Closes #11483
Command outputs YAML to stdout or to a file, allowing the user to create a configuration file from parameters. This assists users with achieving a working tbot configuration as fast as possible.
The
-o
flag can be provided to write the configuration directly to a file, but when this is omitted, the configuration is just output to stdout:golden
This also introduces a test helper package called
golden
. I'm happy to extract this into a separate PR if needs be. I have found golden files to be a very convenient and effective way of handling large expected outputs from tests in a way that can be easily updated, and inspected in PR diffs."Golden files" are expected test outputs stored as files under
testdata/
rather than embedded directly within the test table. Running the tests with the environment variableGOLDEN_UPDATE=1
causes this files to be updated, rather than asserted against.