dentaku/woodpecker-helm3
1
0
Fork 0
Code Pull requests Releases Activity
woodpecker-helm3/internal/env/config_test.go

253 lines
7.7 KiB
Go
Raw Normal View History

Put the Config in a new env package [#67] I'd like to be able to make calls like NewUpgrade(cfg) rather than Upgrade{...}.Prepare, but I wouldn't be able to define a NewUpgrade function while Config is in the helm package; there would be a circular import when Plan tried to import run.
2020-01-14 18:32:20 +00:00
package env
Replicate most of drone-helm's config
2019-12-09 17:56:02 +00:00
import (
Emit warnings about deprecated settings [#10] These aren't an error case--the plugin will work just fine--but users should be aware they (the settings) aren't being respected.
2019-12-31 18:03:53 +00:00
"fmt"
Do envconfig-loading in config.go (and test it!) [#9]
2019-12-23 22:44:59 +00:00
"os"
Log debug output in helm.Config [#9] Redacting KubeToken may not be sufficient, since it's possible that someone would put secrets in Values or StringValues. Unilaterally redacting those seems unhelpful, though, since they may be the very thing the user is trying to debug. I've settled on redacting the obvious field without trying to promise that all sensitive data will be hidden.
2019-12-24 19:08:09 +00:00
"strings"
Replicate most of drone-helm's config
2019-12-09 17:56:02 +00:00
"testing"
Interpolate environment variables in the AddRepos configuration parameter
2020-03-31 22:07:28 +00:00
"github.com/stretchr/testify/suite"
Replicate most of drone-helm's config
2019-12-09 17:56:02 +00:00
)
type ConfigTestSuite struct {
suite.Suite
Do envconfig-loading in config.go (and test it!) [#9]
2019-12-23 22:44:59 +00:00
// These tests need to mutate the environment, so the suite.setenv and .unsetenv functions store the original contents of the
// relevant variable in this map. Its use of *string is so they can distinguish between "not set" and "set to empty string"
envBackup map[string]*string
Replicate most of drone-helm's config
2019-12-09 17:56:02 +00:00
}
func TestConfigTestSuite(t *testing.T) {
suite.Run(t, new(ConfigTestSuite))
}
Do envconfig-loading in config.go (and test it!) [#9]
2019-12-23 22:44:59 +00:00
Use a go-idiomatic constructor for helm.Config [#9]
2019-12-24 17:34:38 +00:00
func (suite *ConfigTestSuite) TestNewConfigWithPluginPrefix() {
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.unsetenv("MODE")
Process non-prefixed forms of all config settings [#9] Trying to guess in advance which part of the config a user will put in the `settings` section and which they'll put in `environment` is a fool's errand. Just let everything go in either place. The ServiceAccount field only had an `envconfig` tag (as opposed to `split_words`) because that triggered envconfig to look for the non- prefixed form. Now that we're finding non-prefixed forms of everything, we can use the clearer/more concise tag. Note that TestPopulateWithConflictingVariables isn't meant to say "here's what behavior we *want*" so much as "here's what the behavior *is*." I don't think one thing is any better than the other, but we should know which one we're getting.
2019-12-23 23:31:40 +00:00
suite.unsetenv("UPDATE_DEPENDENCIES")
suite.unsetenv("DEBUG")
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.setenv("PLUGIN_MODE", "iambic")
Do envconfig-loading in config.go (and test it!) [#9]
2019-12-23 22:44:59 +00:00
suite.setenv("PLUGIN_UPDATE_DEPENDENCIES", "true")
suite.setenv("PLUGIN_DEBUG", "true")
Log debug output in helm.Config [#9] Redacting KubeToken may not be sufficient, since it's possible that someone would put secrets in Values or StringValues. Unilaterally redacting those seems unhelpful, though, since they may be the very thing the user is trying to debug. I've settled on redacting the obvious field without trying to promise that all sensitive data will be hidden.
2019-12-24 19:08:09 +00:00
cfg, err := NewConfig(&strings.Builder{}, &strings.Builder{})
Use a go-idiomatic constructor for helm.Config [#9]
2019-12-24 17:34:38 +00:00
suite.Require().NoError(err)
Do envconfig-loading in config.go (and test it!) [#9]
2019-12-23 22:44:59 +00:00
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.Equal("iambic", cfg.Command)
Do envconfig-loading in config.go (and test it!) [#9]
2019-12-23 22:44:59 +00:00
suite.True(cfg.UpdateDependencies)
suite.True(cfg.Debug)
}
Use a go-idiomatic constructor for helm.Config [#9]
2019-12-24 17:34:38 +00:00
func (suite *ConfigTestSuite) TestNewConfigWithNoPrefix() {
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.unsetenv("PLUGIN_MODE")
Process non-prefixed forms of all config settings [#9] Trying to guess in advance which part of the config a user will put in the `settings` section and which they'll put in `environment` is a fool's errand. Just let everything go in either place. The ServiceAccount field only had an `envconfig` tag (as opposed to `split_words`) because that triggered envconfig to look for the non- prefixed form. Now that we're finding non-prefixed forms of everything, we can use the clearer/more concise tag. Note that TestPopulateWithConflictingVariables isn't meant to say "here's what behavior we *want*" so much as "here's what the behavior *is*." I don't think one thing is any better than the other, but we should know which one we're getting.
2019-12-23 23:31:40 +00:00
suite.unsetenv("PLUGIN_UPDATE_DEPENDENCIES")
suite.unsetenv("PLUGIN_DEBUG")
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.setenv("MODE", "iambic")
Process non-prefixed forms of all config settings [#9] Trying to guess in advance which part of the config a user will put in the `settings` section and which they'll put in `environment` is a fool's errand. Just let everything go in either place. The ServiceAccount field only had an `envconfig` tag (as opposed to `split_words`) because that triggered envconfig to look for the non- prefixed form. Now that we're finding non-prefixed forms of everything, we can use the clearer/more concise tag. Note that TestPopulateWithConflictingVariables isn't meant to say "here's what behavior we *want*" so much as "here's what the behavior *is*." I don't think one thing is any better than the other, but we should know which one we're getting.
2019-12-23 23:31:40 +00:00
suite.setenv("UPDATE_DEPENDENCIES", "true")
suite.setenv("DEBUG", "true")
Log debug output in helm.Config [#9] Redacting KubeToken may not be sufficient, since it's possible that someone would put secrets in Values or StringValues. Unilaterally redacting those seems unhelpful, though, since they may be the very thing the user is trying to debug. I've settled on redacting the obvious field without trying to promise that all sensitive data will be hidden.
2019-12-24 19:08:09 +00:00
cfg, err := NewConfig(&strings.Builder{}, &strings.Builder{})
Use a go-idiomatic constructor for helm.Config [#9]
2019-12-24 17:34:38 +00:00
suite.Require().NoError(err)
Process non-prefixed forms of all config settings [#9] Trying to guess in advance which part of the config a user will put in the `settings` section and which they'll put in `environment` is a fool's errand. Just let everything go in either place. The ServiceAccount field only had an `envconfig` tag (as opposed to `split_words`) because that triggered envconfig to look for the non- prefixed form. Now that we're finding non-prefixed forms of everything, we can use the clearer/more concise tag. Note that TestPopulateWithConflictingVariables isn't meant to say "here's what behavior we *want*" so much as "here's what the behavior *is*." I don't think one thing is any better than the other, but we should know which one we're getting.
2019-12-23 23:31:40 +00:00
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.Equal("iambic", cfg.Command)
Process non-prefixed forms of all config settings [#9] Trying to guess in advance which part of the config a user will put in the `settings` section and which they'll put in `environment` is a fool's errand. Just let everything go in either place. The ServiceAccount field only had an `envconfig` tag (as opposed to `split_words`) because that triggered envconfig to look for the non- prefixed form. Now that we're finding non-prefixed forms of everything, we can use the clearer/more concise tag. Note that TestPopulateWithConflictingVariables isn't meant to say "here's what behavior we *want*" so much as "here's what the behavior *is*." I don't think one thing is any better than the other, but we should know which one we're getting.
2019-12-23 23:31:40 +00:00
suite.True(cfg.UpdateDependencies)
suite.True(cfg.Debug)
}
Use a go-idiomatic constructor for helm.Config [#9]
2019-12-24 17:34:38 +00:00
func (suite *ConfigTestSuite) TestNewConfigWithConflictingVariables() {
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.setenv("PLUGIN_MODE", "iambic")
suite.setenv("MODE", "haiku") // values from the `environment` block override those from `settings`
Allow a configurable env var prefix [#19] I'd like to keep Prefix's scope fairly limited, because it has potential to spiral into something magnificently complex. You get one prefix setting, it goes in `settings` not `environment`, end of feature.
2019-12-24 00:07:49 +00:00
Log debug output in helm.Config [#9] Redacting KubeToken may not be sufficient, since it's possible that someone would put secrets in Values or StringValues. Unilaterally redacting those seems unhelpful, though, since they may be the very thing the user is trying to debug. I've settled on redacting the obvious field without trying to promise that all sensitive data will be hidden.
2019-12-24 19:08:09 +00:00
cfg, err := NewConfig(&strings.Builder{}, &strings.Builder{})
Use a go-idiomatic constructor for helm.Config [#9]
2019-12-24 17:34:38 +00:00
suite.Require().NoError(err)
Process non-prefixed forms of all config settings [#9] Trying to guess in advance which part of the config a user will put in the `settings` section and which they'll put in `environment` is a fool's errand. Just let everything go in either place. The ServiceAccount field only had an `envconfig` tag (as opposed to `split_words`) because that triggered envconfig to look for the non- prefixed form. Now that we're finding non-prefixed forms of everything, we can use the clearer/more concise tag. Note that TestPopulateWithConflictingVariables isn't meant to say "here's what behavior we *want*" so much as "here's what the behavior *is*." I don't think one thing is any better than the other, but we should know which one we're getting.
2019-12-23 23:31:40 +00:00
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.Equal("haiku", cfg.Command)
Process non-prefixed forms of all config settings [#9] Trying to guess in advance which part of the config a user will put in the `settings` section and which they'll put in `environment` is a fool's errand. Just let everything go in either place. The ServiceAccount field only had an `envconfig` tag (as opposed to `split_words`) because that triggered envconfig to look for the non- prefixed form. Now that we're finding non-prefixed forms of everything, we can use the clearer/more concise tag. Note that TestPopulateWithConflictingVariables isn't meant to say "here's what behavior we *want*" so much as "here's what the behavior *is*." I don't think one thing is any better than the other, but we should know which one we're getting.
2019-12-23 23:31:40 +00:00
}
Shim bare numbers into duration strings [#39] Helm2's --timeout took a number of seconds, rather than the ParseDuration-compatible string that helm3 uses. For backward- compatibility, update a bare number into a duration string.
2019-12-28 00:18:10 +00:00
func (suite *ConfigTestSuite) TestNewConfigInfersNumbersAreSeconds() {
suite.setenv("PLUGIN_TIMEOUT", "42")
cfg, err := NewConfig(&strings.Builder{}, &strings.Builder{})
suite.Require().NoError(err)
suite.Equal("42s", cfg.Timeout)
}
Rough draft of aliased settings [#66]
2020-01-07 23:25:54 +00:00
func (suite *ConfigTestSuite) TestNewConfigWithAliases() {
for _, varname := range []string{
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
"MODE",
"ADD_REPOS",
"KUBE_API_SERVER",
"KUBE_SERVICE_ACCOUNT",
"WAIT_FOR_UPGRADE",
"FORCE_UPGRADE",
"KUBE_TOKEN",
"KUBE_CERTIFICATE",
Rough draft of aliased settings [#66]
2020-01-07 23:25:54 +00:00
} {
suite.unsetenv(varname)
suite.unsetenv("PLUGIN_" + varname)
}
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.setenv("PLUGIN_HELM_COMMAND", "beware the jabberwock")
suite.setenv("PLUGIN_HELM_REPOS", "chortle=http://calloo.callay/frabjous/day")
suite.setenv("PLUGIN_API_SERVER", "http://tumtum.tree")
suite.setenv("PLUGIN_SERVICE_ACCOUNT", "tulgey")
suite.setenv("PLUGIN_WAIT", "true")
suite.setenv("PLUGIN_FORCE", "true")
suite.setenv("PLUGIN_KUBERNETES_TOKEN", "Y29tZSB0byBteSBhcm1z")
suite.setenv("PLUGIN_KUBERNETES_CERTIFICATE", "d2l0aCBpdHMgaGVhZA==")
Rough draft of aliased settings [#66]
2020-01-07 23:25:54 +00:00
cfg, err := NewConfig(&strings.Builder{}, &strings.Builder{})
suite.Require().NoError(err)
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.Equal("beware the jabberwock", cfg.Command)
Rough draft of aliased settings [#66]
2020-01-07 23:25:54 +00:00
suite.Equal([]string{"chortle=http://calloo.callay/frabjous/day"}, cfg.AddRepos)
suite.Equal("http://tumtum.tree", cfg.APIServer)
suite.Equal("tulgey", cfg.ServiceAccount)
suite.True(cfg.Wait, "Wait should be aliased")
suite.True(cfg.Force, "Force should be aliased")
Use "kube" in setting aliases [#66] Nobody likes typing "kubernetes"! Writing out that whole word without typos is the third hard problem in computer science.
2020-01-07 23:39:05 +00:00
suite.Equal("Y29tZSB0byBteSBhcm1z", cfg.KubeToken, "KubeToken should be aliased")
suite.Equal("d2l0aCBpdHMgaGVhZA==", cfg.Certificate, "Certificate should be aliased")
Rough draft of aliased settings [#66]
2020-01-07 23:25:54 +00:00
}
Test settings aliases without the plugin_ prefix [#66]
2020-01-08 20:37:34 +00:00
func (suite *ConfigTestSuite) TestAliasedSettingWithoutPluginPrefix() {
suite.unsetenv("FORCE_UPGRADE")
suite.unsetenv("PLUGIN_FORCE_UPGRADE")
suite.unsetenv("PLUGIN_FORCE")
suite.setenv("FORCE", "true")
cfg, err := NewConfig(&strings.Builder{}, &strings.Builder{})
suite.Require().NoError(err)
suite.True(cfg.Force)
}
Stabilize the logic for setting-alias conflicts [#66] This includes a refactor to the way aliases are processed. I had been thinking in terms of locking down the aliases names pretty tightly, in order to provide an error if there are conflicts. After discussion with @josmo, though, it seems like we can do it the same way we do for "PLUGIN_"/non-prefixed variables, i.e. quietly override them.
2020-01-08 17:31:22 +00:00
func (suite *ConfigTestSuite) TestNewConfigWithAliasConflicts() {
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.unsetenv("FORCE_UPGRADE")
suite.setenv("PLUGIN_FORCE", "true")
suite.setenv("PLUGIN_FORCE_UPGRADE", "false") // should override even when set to the zero value
Stabilize the logic for setting-alias conflicts [#66] This includes a refactor to the way aliases are processed. I had been thinking in terms of locking down the aliases names pretty tightly, in order to provide an error if there are conflicts. After discussion with @josmo, though, it seems like we can do it the same way we do for "PLUGIN_"/non-prefixed variables, i.e. quietly override them.
2020-01-08 17:31:22 +00:00
cfg, err := NewConfig(&strings.Builder{}, &strings.Builder{})
suite.NoError(err)
suite.False(cfg.Force, "official names should override alias names")
}
Log debug output in helm.Config [#9] Redacting KubeToken may not be sufficient, since it's possible that someone would put secrets in Values or StringValues. Unilaterally redacting those seems unhelpful, though, since they may be the very thing the user is trying to debug. I've settled on redacting the obvious field without trying to promise that all sensitive data will be hidden.
2019-12-24 19:08:09 +00:00
func (suite *ConfigTestSuite) TestNewConfigSetsWriters() {
stdout := &strings.Builder{}
stderr := &strings.Builder{}
cfg, err := NewConfig(stdout, stderr)
suite.Require().NoError(err)
suite.Equal(stdout, cfg.Stdout)
suite.Equal(stderr, cfg.Stderr)
}
Emit warnings about deprecated settings [#10] These aren't an error case--the plugin will work just fine--but users should be aware they (the settings) aren't being respected.
2019-12-31 18:03:53 +00:00
func (suite *ConfigTestSuite) TestDeprecatedSettingWarnings() {
for _, varname := range deprecatedVars {
suite.setenv(varname, "deprecoat") // environment-block entries should cause warnings
}
suite.unsetenv("PURGE")
suite.setenv("PLUGIN_PURGE", "true") // settings-block entries should cause warnings
suite.setenv("UPGRADE", "") // entries should cause warnings even when set to empty string
stderr := &strings.Builder{}
_, err := NewConfig(&strings.Builder{}, stderr)
suite.NoError(err)
for _, varname := range deprecatedVars {
suite.Contains(stderr.String(), fmt.Sprintf("Warning: ignoring deprecated '%s' setting\n", strings.ToLower(varname)))
}
}
Log debug output in helm.Config [#9] Redacting KubeToken may not be sufficient, since it's possible that someone would put secrets in Values or StringValues. Unilaterally redacting those seems unhelpful, though, since they may be the very thing the user is trying to debug. I've settled on redacting the obvious field without trying to promise that all sensitive data will be hidden.
2019-12-24 19:08:09 +00:00
func (suite *ConfigTestSuite) TestLogDebug() {
suite.setenv("DEBUG", "true")
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
suite.setenv("MODE", "upgrade")
Log debug output in helm.Config [#9] Redacting KubeToken may not be sufficient, since it's possible that someone would put secrets in Values or StringValues. Unilaterally redacting those seems unhelpful, though, since they may be the very thing the user is trying to debug. I've settled on redacting the obvious field without trying to promise that all sensitive data will be hidden.
2019-12-24 19:08:09 +00:00
stderr := strings.Builder{}
stdout := strings.Builder{}
_, err := NewConfig(&stdout, &stderr)
suite.Require().NoError(err)
suite.Equal("", stdout.String())
suite.Regexp(`^Generated config: \{Command:upgrade.*\}`, stderr.String())
}
func (suite *ConfigTestSuite) TestLogDebugCensorsKubeToken() {
stderr := &strings.Builder{}
kubeToken := "I'm shy! Don't put me in your build logs!"
cfg := Config{
Debug: true,
KubeToken: kubeToken,
Stderr: stderr,
}
cfg.logDebug()
suite.Contains(stderr.String(), "KubeToken:(redacted)")
suite.Equal(kubeToken, cfg.KubeToken) // The actual config value should be left unchanged
}
Expand env vars in Values/StringValues [#34]
2020-01-21 23:37:59 +00:00
func (suite *ConfigTestSuite) TestNewConfigWithValuesSecrets() {
suite.unsetenv("VALUES")
suite.unsetenv("STRING_VALUES")
Avoid polluted-env problems in config tests [#34] I mean...it's *possible* someone will have SECRET_WATER set in their env, right? Might as well be paranoid; it doesn't cost much.
2020-01-22 00:25:58 +00:00
suite.unsetenv("SECRET_WATER")
Expand env vars in Values/StringValues [#34]
2020-01-21 23:37:59 +00:00
suite.setenv("SECRET_FIRE", "Eru_Ilúvatar")
suite.setenv("SECRET_RINGS", "1")
suite.setenv("PLUGIN_VALUES", "fire=$SECRET_FIRE,water=${SECRET_WATER}")
suite.setenv("PLUGIN_STRING_VALUES", "rings=${SECRET_RINGS}")
Interpolate environment variables in the AddRepos configuration parameter
2020-03-31 22:07:28 +00:00
suite.setenv("PLUGIN_ADD_REPOS", "testrepo=https://user:${SECRET_FIRE}@testrepo.test")
Expand env vars in Values/StringValues [#34]
2020-01-21 23:37:59 +00:00
cfg, err := NewConfig(&strings.Builder{}, &strings.Builder{})
suite.Require().NoError(err)
suite.Equal("fire=Eru_Ilúvatar,water=", cfg.Values)
suite.Equal("rings=1", cfg.StringValues)
Interpolate environment variables in the AddRepos configuration parameter
2020-03-31 22:07:28 +00:00
suite.Equal(fmt.Sprintf("testrepo=https://user:%s@testrepo.test", os.Getenv("SECRET_FIRE")), cfg.AddRepos[0])
Expand env vars in Values/StringValues [#34]
2020-01-21 23:37:59 +00:00
}
Log debug information in loadValuesSecrets [#34]
2020-01-22 00:04:05 +00:00
func (suite *ConfigTestSuite) TestValuesSecretsWithDebugLogging() {
suite.unsetenv("VALUES")
Avoid polluted-env problems in config tests [#34] I mean...it's *possible* someone will have SECRET_WATER set in their env, right? Might as well be paranoid; it doesn't cost much.
2020-01-22 00:25:58 +00:00
suite.unsetenv("SECRET_WATER")
Log debug information in loadValuesSecrets [#34]
2020-01-22 00:04:05 +00:00
suite.setenv("SECRET_FIRE", "Eru_Ilúvatar")
suite.setenv("PLUGIN_DEBUG", "true")
suite.setenv("PLUGIN_STRING_VALUES", "fire=$SECRET_FIRE")
suite.setenv("PLUGIN_VALUES", "fire=$SECRET_FIRE,water=$SECRET_WATER")
stderr := strings.Builder{}
_, err := NewConfig(&strings.Builder{}, &stderr)
suite.Require().NoError(err)
Don't bother trying to hide secrets in values [#34] While testing this I discovered the secrets are revealed anyway, since the lint/upgrade jobs' debug output includes the command they generated. Might as well make the code a little simpler.
2020-01-22 00:23:55 +00:00
suite.Contains(stderr.String(), "Values:fire=Eru_Ilúvatar,water=")
suite.Contains(stderr.String(), `$SECRET_WATER not present in environment, replaced with ""`)
Log debug information in loadValuesSecrets [#34]
2020-01-22 00:04:05 +00:00
}
Do envconfig-loading in config.go (and test it!) [#9]
2019-12-23 22:44:59 +00:00
func (suite *ConfigTestSuite) setenv(key, val string) {
orig, ok := os.LookupEnv(key)
if ok {
suite.envBackup[key] = &orig
} else {
suite.envBackup[key] = nil
}
os.Setenv(key, val)
}
func (suite *ConfigTestSuite) unsetenv(key string) {
orig, ok := os.LookupEnv(key)
if ok {
suite.envBackup[key] = &orig
} else {
suite.envBackup[key] = nil
}
os.Unsetenv(key)
}
func (suite *ConfigTestSuite) BeforeTest(_, _ string) {
suite.envBackup = make(map[string]*string)
}
func (suite *ConfigTestSuite) AfterTest(_, _ string) {
for key, val := range suite.envBackup {
if val == nil {
os.Unsetenv(key)
} else {
os.Setenv(key, *val)
}
}
}
Copy permalink