-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Support using short names for config keys #422
Conversation
Previously, you had to fully qualify configuration values (e.g example:config:message). As a convience, let's support adding configuration values where the key is not a fully qualified module member. In this case, we'll treat the key as if `<program-name>:config:` had been prepended to it. In addition, when we print config, shorten keys of the form `<program-name>:config:<key-name>` to `<key-name>`. I've updated one integration test to use the new syntax and left the other as is to ensure both continue to work.
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.
Sweet 👍
return tokens.ParseModuleMember(key) | ||
} | ||
|
||
func prettyKey(key string) string { |
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.
Probably worth a handful of little unit tests.
return "", err | ||
} | ||
|
||
return tokens.ParseModuleMember(fmt.Sprintf("%s:config:%s", pkg.Name, key)) |
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.
We decided to nix the config:
part, right? Is that planned for a later change?
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.
Later change.
@@ -99,3 +102,40 @@ func displayEvents(events <-chan engine.Event, done chan bool, debug bool) { | |||
} | |||
} | |||
} | |||
|
|||
func getPackage() (string, pack.Package, error) { |
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 are keeping workspace
, might make sense to have in there as a general helper utility.
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.
Sure, I do that in a follow up PR.
b639e8c
to
6d01146
Compare
6d01146
to
c8897d0
Compare
11570: testing: Allow plugin testing users to define their own plugin sets r=AaronFriel a=AaronFriel Updating Pulumi YAML to address pulumi/pulumi-yaml#421 and pulumi/pulumi-yaml#422, requires testing against the Docker v4.0.0-alpha.0 schema. That required updating this repo, and using Go workspaces/module replacement to allow the deploytest plugin loader to find the prerelease schema. This change allows Pulumi YAML to define its own set of required plugins, decoupling the two repos and preventing the catch-22 here. Because this repo will need to support the new example being authored which will serve as a test of #421 and #422, this also adds Docker v4.0.0-alpha.0 as a schema. Co-authored-by: Aaron Friel <[email protected]>
11570: testing: Allow plugin testing users to define their own plugin sets r=AaronFriel a=AaronFriel Updating Pulumi YAML to address pulumi/pulumi-yaml#421 and pulumi/pulumi-yaml#422, requires testing against the Docker v4.0.0-alpha.0 schema. That required updating this repo, and using Go workspaces/module replacement to allow the deploytest plugin loader to find the prerelease schema. This change allows Pulumi YAML to define its own set of required plugins, decoupling the two repos and preventing the catch-22 here. Because this repo will need to support the new example being authored which will serve as a test of #421 and #422, this also adds Docker v4.0.0-alpha.0 as a schema. Co-authored-by: Aaron Friel <[email protected]>
Previously, you had to fully qualify configuration values (e.g
example:config:message). As a convience, let's support adding
configuration values where the key is not a fully qualified module
member. In this case, we'll treat the key as if
<program-name>:config:
had been prepended to it.In addition, when we print config, shorten keys of the form
<program-name>:config:<key-name>
to<key-name>
.I've updated one integration test to use the new syntax and left the
other as is to ensure both continue to work.