pulumi/cmd/config.go

456 lines
11 KiB
Go
Raw Normal View History

2017-06-26 23:46:34 +02:00
// Copyright 2016-2017, Pulumi Corporation. All rights reserved.
package cmd
import (
"fmt"
"sort"
"strings"
"github.com/pulumi/pulumi/pkg/util/contract"
2017-10-18 19:10:04 +02:00
"github.com/pulumi/pulumi/pkg/pack"
"github.com/pulumi/pulumi/pkg/resource/config"
2017-10-18 19:10:04 +02:00
"github.com/pkg/errors"
"github.com/spf13/cobra"
"github.com/pulumi/pulumi/pkg/tokens"
"github.com/pulumi/pulumi/pkg/util/cmdutil"
)
func newConfigCmd() *cobra.Command {
cmd := &cobra.Command{
Use: "config",
Short: "Manage configuration",
}
cmd.AddCommand(newConfigLsCmd())
cmd.AddCommand(newConfigRmCmd())
cmd.AddCommand(newConfigTextCmd())
cmd.AddCommand(newConfigSecretCmd())
return cmd
}
func newConfigLsCmd() *cobra.Command {
var stack string
var showSecrets bool
lsCmd := &cobra.Command{
Use: "ls [key]",
Short: "List configuration for a stack",
Args: cobra.MaximumNArgs(1),
Run: cmdutil.RunFunc(func(cmd *cobra.Command, args []string) error {
stackName, err := explicitOrCurrent(stack, backend)
if err != nil {
return err
}
if len(args) == 1 {
key, err := parseConfigKey(args[0])
if err != nil {
return errors.Wrap(err, "invalid configuration key")
}
return getConfig(stackName, key)
}
return listConfig(stackName, showSecrets)
}),
}
lsCmd.PersistentFlags().StringVarP(
&stack, "stack", "s", "",
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
"List configuration for a different stack than the currently selected stack")
lsCmd.PersistentFlags().BoolVar(
&showSecrets, "show-secrets", false,
"Show secret values when listing config instead of displaying blinded values")
return lsCmd
}
func newConfigRmCmd() *cobra.Command {
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
var all bool
var save bool
var stack string
rmCmd := &cobra.Command{
Use: "rm <key>",
Short: "Remove configuration value",
Args: cobra.ExactArgs(1),
Run: cmdutil.RunFunc(func(cmd *cobra.Command, args []string) error {
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
if all && stack != "" {
return errors.New("if --all is specified, an explicit stack can not be provided")
}
var stackName tokens.QName
if !all {
var err error
if stackName, err = explicitOrCurrent(stack, backend); err != nil {
return err
}
}
key, err := parseConfigKey(args[0])
if err != nil {
return errors.Wrap(err, "invalid configuration key")
}
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
if save {
return deleteProjectConfiguration(stackName, key)
}
return deleteWorkspaceConfiguration(stackName, key)
}),
}
rmCmd.PersistentFlags().StringVarP(
&stack, "stack", "s", "",
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
"Target a specific stack instead of the default stack")
rmCmd.PersistentFlags().BoolVar(
&save, "save", false,
"Remove the configuration value in the project file instead instead of a locally set value")
rmCmd.PersistentFlags().BoolVar(
&all, "all", false,
"Remove a project wide configuration value that applies to all stacks")
return rmCmd
}
func newConfigTextCmd() *cobra.Command {
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
var all bool
var save bool
var stack string
textCmd := &cobra.Command{
Use: "text <key> <value>",
Short: "Set configuration value",
Args: cobra.ExactArgs(2),
Run: cmdutil.RunFunc(func(cmd *cobra.Command, args []string) error {
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
if all && stack != "" {
return errors.New("if --all is specified, an explicit stack can not be provided")
}
var stackName tokens.QName
if !all {
var err error
if stackName, err = explicitOrCurrent(stack, backend); err != nil {
return err
}
}
key, err := parseConfigKey(args[0])
if err != nil {
return errors.Wrap(err, "invalid configuration key")
}
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
return setConfiguration(stackName, key, config.NewValue(args[1]), save)
}),
}
textCmd.PersistentFlags().StringVarP(
&stack, "stack", "s", "",
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
"Target a specific stack instead of the default stack")
textCmd.PersistentFlags().BoolVar(
&save, "save", false,
"Save the configuration value in the project file instead of locally")
textCmd.PersistentFlags().BoolVar(
&all, "all", false,
"Set a configuration value for all stacks for this project")
return textCmd
}
func newConfigSecretCmd() *cobra.Command {
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
var all bool
var save bool
var stack string
secretCmd := &cobra.Command{
Use: "secret <key> [value]",
Short: "Set an encrypted configuration value",
Args: cobra.RangeArgs(1, 2),
Run: cmdutil.RunFunc(func(cmd *cobra.Command, args []string) error {
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
if all && stack != "" {
return errors.New("if --all is specified, an explicit stack can not be provided")
}
var stackName tokens.QName
if !all {
var err error
if stackName, err = explicitOrCurrent(stack, backend); err != nil {
return err
}
}
key, err := parseConfigKey(args[0])
if err != nil {
return errors.Wrap(err, "invalid configuration key")
}
c, err := getSymmetricCrypter()
if err != nil {
return err
}
var value string
if len(args) == 2 {
value = args[1]
} else {
value, err = readConsoleNoEchoWithPrompt("value")
if err != nil {
return err
}
}
encryptedValue, err := c.EncryptValue(value)
if err != nil {
return err
}
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
return setConfiguration(stackName, key, config.NewSecureValue(encryptedValue), save)
}),
}
secretCmd.PersistentFlags().StringVarP(
&stack, "stack", "s", "",
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
"Target a specific stack instead of the default stack")
secretCmd.PersistentFlags().BoolVar(
&save, "save", false,
"Save the configuration value in the project file instead of locally")
secretCmd.PersistentFlags().BoolVar(
&all, "all", false,
"Set a configuration value for all stacks for this project")
return secretCmd
}
func parseConfigKey(key string) (tokens.ModuleMember, error) {
// As a convience, we'll treat any key with no delimiter as if:
// <program-name>:config:<key> had been written instead
if !strings.Contains(key, tokens.TokenDelimiter) {
pkg, err := getPackage()
if err != nil {
return "", err
}
return tokens.ParseModuleMember(fmt.Sprintf("%s:config:%s", pkg.Name, key))
}
return tokens.ParseModuleMember(key)
}
func prettyKey(key string) string {
pkg, err := getPackage()
if err != nil {
return key
}
2017-10-18 19:10:04 +02:00
return prettyKeyForPackage(key, pkg)
}
func prettyKeyForPackage(key string, pkg *pack.Package) string {
s := key
defaultPrefix := fmt.Sprintf("%s:config:", pkg.Name)
if strings.HasPrefix(s, defaultPrefix) {
return s[len(defaultPrefix):]
}
return s
}
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
func setConfiguration(stackName tokens.QName, key tokens.ModuleMember, value config.Value, save bool) error {
if save {
return setProjectConfiguration(stackName, key, value)
}
return setWorkspaceConfiguration(stackName, key, value)
}
func listConfig(stackName tokens.QName, showSecrets bool) error {
cfg, err := getConfiguration(stackName)
if err != nil {
return err
}
var decrypter config.ValueDecrypter = blindingDecrypter{}
if hasSecureValue(cfg) && showSecrets {
decrypter, err = getSymmetricCrypter()
if err != nil {
return err
}
}
if cfg != nil {
fmt.Printf("%-32s %-32s\n", "KEY", "VALUE")
var keys []string
for key := range cfg {
// Note that we use the fully qualified module member here instead of a `prettyKey`, this lets us ensure that all the config
// values for the current program are displayed next to one another in the output.
keys = append(keys, string(key))
}
sort.Strings(keys)
for _, key := range keys {
decrypted, err := cfg[tokens.ModuleMember(key)].Value(decrypter)
if err != nil {
return errors.Wrap(err, "could not decrypt configuration value")
}
fmt.Printf("%-32s %-32s\n", prettyKey(key), decrypted)
}
}
return nil
}
func getConfig(stackName tokens.QName, key tokens.ModuleMember) error {
cfg, err := getConfiguration(stackName)
if err != nil {
return err
}
if cfg != nil {
if v, ok := cfg[key]; ok {
var decrypter config.ValueDecrypter = panicCrypter{}
if v.Secure() {
decrypter, err = getSymmetricCrypter()
if err != nil {
return err
}
}
decrypted, err := v.Value(decrypter)
if err != nil {
return errors.Wrap(err, "could not decrypt configuation value")
}
fmt.Printf("%v\n", decrypted)
return nil
}
}
return errors.Errorf("configuration key '%v' not found for stack '%v'", prettyKey(key.String()), stackName)
2017-10-10 02:09:32 +02:00
}
func getConfiguration(stackName tokens.QName) (map[tokens.ModuleMember]config.Value, error) {
contract.Require(stackName != "", "stackName")
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
workspace, err := newWorkspace()
if err != nil {
return nil, err
}
pkg, err := getPackage()
2017-10-10 02:09:32 +02:00
if err != nil {
return nil, err
}
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
configs := make([]map[tokens.ModuleMember]config.Value, 4)
configs = append(configs, pkg.Config)
if stackInfo, has := pkg.Stacks[stackName]; has {
configs = append(configs, stackInfo.Config)
}
if localAllStackConfig, has := workspace.Settings().Config[""]; has {
configs = append(configs, localAllStackConfig)
}
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
if localStackConfig, has := workspace.Settings().Config[stackName]; has {
configs = append(configs, localStackConfig)
}
return mergeConfigs(configs...), nil
}
2017-10-10 02:14:21 +02:00
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
func deleteProjectConfiguration(stackName tokens.QName, key tokens.ModuleMember) error {
pkg, err := getPackage()
2017-10-10 02:14:21 +02:00
if err != nil {
return err
}
if stackName == "" {
if pkg.Config != nil {
delete(pkg.Config, key)
}
} else {
if pkg.Stacks[stackName].Config != nil {
delete(pkg.Stacks[stackName].Config, key)
}
2017-10-10 02:14:21 +02:00
}
return savePackage(pkg)
2017-10-10 02:14:21 +02:00
}
2017-10-10 02:25:44 +02:00
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
func deleteWorkspaceConfiguration(stackName tokens.QName, key tokens.ModuleMember) error {
workspace, err := newWorkspace()
if err != nil {
return err
}
if config, has := workspace.Settings().Config[stackName]; has {
delete(config, key)
}
return workspace.Save()
}
func setProjectConfiguration(stackName tokens.QName, key tokens.ModuleMember, value config.Value) error {
pkg, err := getPackage()
2017-10-10 02:25:44 +02:00
if err != nil {
return err
}
if stackName == "" {
if pkg.Config == nil {
pkg.Config = make(map[tokens.ModuleMember]config.Value)
}
pkg.Config[key] = value
} else {
if pkg.Stacks == nil {
pkg.Stacks = make(map[tokens.QName]pack.StackInfo)
}
if pkg.Stacks[stackName].Config == nil {
si := pkg.Stacks[stackName]
si.Config = make(map[tokens.ModuleMember]config.Value)
pkg.Stacks[stackName] = si
}
pkg.Stacks[stackName].Config[key] = value
}
return savePackage(pkg)
}
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
func setWorkspaceConfiguration(stackName tokens.QName, key tokens.ModuleMember, value config.Value) error {
workspace, err := newWorkspace()
if err != nil {
return err
}
2017-10-10 02:25:44 +02:00
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
if _, has := workspace.Settings().Config[stackName]; !has {
workspace.Settings().Config[stackName] = make(map[tokens.ModuleMember]config.Value)
2017-10-10 02:25:44 +02:00
}
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
workspace.Settings().Config[stackName][key] = value
return workspace.Save()
}
func mergeConfigs(configs ...map[tokens.ModuleMember]config.Value) map[tokens.ModuleMember]config.Value {
merged := make(map[tokens.ModuleMember]config.Value)
2017-10-10 02:25:44 +02:00
Suport workspace local configuration and use it by default Previously, we stored configuration information in the Pulumi.yaml file. This was a change from the old model where configuration was stored in a special section of the checkpoint file. While doing things this way has some upsides with being able to flow configuration changes with your source code (e.g. fixed values for a production stack that version with the code) it caused some friction for the local development scinerio. In this case, setting configuration values would pend changes to Pulumi.yaml and if you didn't want to publish these changes, you'd have to remember to remove them before commiting. It also was problematic for our examples, where it was not clear if we wanted to actually include values like `aws:config:region` in our samples. Finally, we found that for our own pulumi service, we'd have values that would differ across each individual dev stack, and publishing these values to a global Pulumi.yaml file would just be adding noise to things. We now adopt a hybrid model, where by default configuration is stored locally, in the workspace's settings per project. A new flag `--save` tests commands to actual operate on the configuration information stored in Pulumi.yaml. With the following change, we have have four "slots" configuration values can end up in: 1. In the Pulumi.yaml file, applies to all stacks 2. In the Pulumi.yaml file, applied to a specific stack 3. In the local workspace.json file, applied to all stacks 4. In the local workspace.json file, applied to a specific stack When computing the configuration information for a stack, we apply configuration in the above order, overriding values as we go along. We also invert the default behavior of the `pulumi config` commands so they operate on a specific stack (i.e. how they did before e3610989). If you want to apply configuration to all stacks, `--all` can be passed to any configuration command.
2017-10-27 23:24:47 +02:00
for _, config := range configs {
for key, value := range config {
merged[key] = value
}
}
return merged
2017-10-10 02:25:44 +02:00
}