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

161 lines
7.1 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
Do envconfig-loading in config.go (and test it!) [#9]
2019-12-23 22:44:59 +00:00
import (
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
"fmt"
"io"
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
"os"
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
"regexp"
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
"strings"
Interpolate environment variables in the AddRepos configuration parameter
2020-03-31 22:07:28 +00:00
"github.com/kelseyhightower/envconfig"
Do envconfig-loading in config.go (and test it!) [#9]
2019-12-23 22:44:59 +00:00
)
Replicate most of drone-helm's config
2019-12-09 17:56:02 +00:00
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
var (
justNumbers = regexp.MustCompile(`^\d+$`)
deprecatedVars = []string{"PURGE", "RECREATE_PODS", "TILLER_NS", "UPGRADE", "CANARY_IMAGE", "CLIENT_ONLY", "STABLE_REPO_URL"}
)
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
No typo inthe helm.Config docs [#9]
2019-12-23 22:03:51 +00:00
// The Config struct captures the `settings` and `environment` blocks in the application's drone
Brush all the lint off this code I wrote in a haze
2019-12-09 18:52:41 +00:00
// config. Configuration in drone's `settings` block arrives as uppercase env vars matching the
Document the Config struct's behavior correctly [#19] [#9]
2019-12-24 00:45:09 +00:00
// config key, prefixed with `PLUGIN_`. Config from the `environment` block is uppercased, but does
Remove support for the prefix setting [#48] The setting isn't necessary with modern versions of Drone, and it creates a lot of edge-cases. The use-case doesn't justify the added complexity.
2019-12-31 17:28:42 +00:00
// not have the `PLUGIN_` prefix.
Replicate most of drone-helm's config
2019-12-09 17:56:02 +00:00
type Config struct {
// Configuration for drone-helm itself
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
Command string `envconfig:"mode"` // Helm command to run
Use lowercase envconfig tags throughout Config Followup to discussion on #75. The important part is to have them consistent, and I like the lowercase a little better since it matches the casing in parameter_reference.md (and the code doesn't yell at me :))
2020-01-20 18:54:52 +00:00
DroneEvent string `envconfig:"drone_build_event"` // Drone event that invoked this plugin.
Add dependencies_action configuration option
2020-04-05 12:22:46 +00:00
UpdateDependencies bool `split_words:"true"` // [Deprecated] Call `helm dependency update` before the main command (deprecated, use dependencies_action: update instead)
DependenciesAction string `split_words:"true"` // Call `helm dependency build` or `helm dependency update` before the main command
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
AddRepos []string `split_words:"true"` // Call `helm repo add` before the main command
Use base64 strings for chart repo certs [#74] This should be a more flexible option since certificates aren't likely to be part of the actual workspace and may be environment-dependent. It also mirrors the kube_certificate, which is nice.
2020-01-20 23:40:36 +00:00
RepoCertificate string `envconfig:"repo_certificate"` // The Helm chart repository's self-signed certificate (must be base64-encoded)
RepoCACertificate string `envconfig:"repo_ca_certificate"` // The Helm chart repository CA's self-signed certificate (must be base64-encoded)
Use a plain string for helm.Config.Command [#9] I'm leaving the no-op test file in place because my next step is to add new behavior that will require testing.
2019-12-23 22:06:05 +00:00
Debug bool `` // Generate debug output and pass --debug to all helm commands
Values string `` // Argument to pass to --set in applicable helm commands
StringValues string `split_words:"true"` // Argument to pass to --set-string in applicable helm commands
ValuesFiles []string `split_words:"true"` // Arguments to pass to --values in applicable helm commands
Namespace string `` // Kubernetes namespace for all helm commands
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
KubeToken string `split_words:"true"` // Kubernetes authentication token to put in .kube/config
Use lowercase envconfig tags throughout Config Followup to discussion on #75. The important part is to have them consistent, and I like the lowercase a little better since it matches the casing in parameter_reference.md (and the code doesn't yell at me :))
2020-01-20 18:54:52 +00:00
SkipTLSVerify bool `envconfig:"skip_tls_verify"` // Put insecure-skip-tls-verify in .kube/config
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
Certificate string `envconfig:"kube_certificate"` // The Kubernetes cluster CA's self-signed certificate (must be base64-encoded)
APIServer string `envconfig:"kube_api_server"` // The Kubernetes cluster's API endpoint
ServiceAccount string `envconfig:"kube_service_account"` // Account to use for connecting to the Kubernetes cluster
Use a plain string for helm.Config.Command [#9] I'm leaving the no-op test file in place because my next step is to add new behavior that will require testing.
2019-12-23 22:06:05 +00:00
ChartVersion string `split_words:"true"` // Specific chart version to use in `helm upgrade`
DryRun bool `split_words:"true"` // Pass --dry-run to applicable helm commands
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
Wait bool `envconfig:"wait_for_upgrade"` // Pass --wait to applicable helm commands
Use a plain string for helm.Config.Command [#9] I'm leaving the no-op test file in place because my next step is to add new behavior that will require testing.
2019-12-23 22:06:05 +00:00
ReuseValues bool `split_words:"true"` // Pass --reuse-values to `helm upgrade`
Pass --keep-history when so instructed [#24]
2020-01-02 18:58:58 +00:00
KeepHistory bool `split_words:"true"` // Pass --keep-history to `helm uninstall`
Use a plain string for helm.Config.Command [#9] I'm leaving the no-op test file in place because my next step is to add new behavior that will require testing.
2019-12-23 22:06:05 +00:00
Timeout string `` // Argument to pass to --timeout in applicable helm commands
Chart string `` // Chart argument to use in applicable helm commands
Release string `` // Release argument to use in applicable helm commands
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
Force bool `envconfig:"force_upgrade"` // Pass --force to applicable helm commands
Pass an atomic_upgrade setting to the Upgrade step [#64]
2020-01-07 20:21:55 +00:00
AtomicUpgrade bool `split_words:"true"` // Pass --atomic to `helm upgrade`
Use lowercase envconfig tags throughout Config Followup to discussion on #75. The important part is to have them consistent, and I like the lowercase a little better since it matches the casing in parameter_reference.md (and the code doesn't yell at me :))
2020-01-20 18:54:52 +00:00
CleanupOnFail bool `envconfig:"cleanup_failed_upgrade"` // Pass --cleanup-on-fail to `helm upgrade`
Pass --strict to `helm lint` when so instructed [#28]
2020-01-02 19:25:13 +00:00
LintStrictly bool `split_words:"true"` // Pass --strict to `helm lint`
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
Stdout io.Writer `ignored:"true"`
Stderr io.Writer `ignored:"true"`
Replicate most of drone-helm's config
2019-12-09 17:56:02 +00:00
}
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
// NewConfig creates a Config and reads environment variables into it, accounting for several possible formats.
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 NewConfig(stdout, stderr io.Writer) (*Config, error) {
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
var aliases settingAliases
if err := envconfig.Process("plugin", &aliases); err != nil {
return nil, err
}
if err := envconfig.Process("", &aliases); err != nil {
return nil, err
}
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 := Config{
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
Command: aliases.Command,
AddRepos: aliases.AddRepos,
APIServer: aliases.APIServer,
ServiceAccount: aliases.ServiceAccount,
Wait: aliases.Wait,
Force: aliases.Force,
KubeToken: aliases.KubeToken,
Certificate: aliases.Certificate,
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
Stdout: stdout,
Stderr: stderr,
}
Use a go-idiomatic constructor for helm.Config [#9]
2019-12-24 17:34:38 +00:00
if err := envconfig.Process("plugin", &cfg); err != nil {
return nil, 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
}
Use a go-idiomatic constructor for helm.Config [#9]
2019-12-24 17:34:38 +00:00
if err := envconfig.Process("", &cfg); err != nil {
return nil, 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
}
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
if justNumbers.MatchString(cfg.Timeout) {
cfg.Timeout = fmt.Sprintf("%ss", cfg.Timeout)
}
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
cfg.loadValuesSecrets()
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
if cfg.Debug && cfg.Stderr != nil {
cfg.logDebug()
}
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
cfg.deprecationWarn()
Use a go-idiomatic constructor for helm.Config [#9]
2019-12-24 17:34:38 +00:00
return &cfg, nil
Do envconfig-loading in config.go (and test it!) [#9]
2019-12-23 22:44:59 +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
Expand env vars in Values/StringValues [#34]
2020-01-21 23:37:59 +00:00
func (cfg *Config) loadValuesSecrets() {
findVar := regexp.MustCompile(`\$\{?(\w+)\}?`)
replacer := func(varName string) string {
sigils := regexp.MustCompile(`[${}]`)
varName = sigils.ReplaceAllString(varName, "")
if value, ok := os.LookupEnv(varName); ok {
return value
}
Log debug information in loadValuesSecrets [#34]
2020-01-22 00:04:05 +00:00
if cfg.Debug {
fmt.Fprintf(cfg.Stderr, "$%s not present in environment, replaced with \"\"\n", varName)
}
Expand env vars in Values/StringValues [#34]
2020-01-21 23:37:59 +00:00
return ""
}
cfg.Values = findVar.ReplaceAllStringFunc(cfg.Values, replacer)
cfg.StringValues = findVar.ReplaceAllStringFunc(cfg.StringValues, replacer)
Interpolate environment variables in the AddRepos configuration parameter
2020-03-31 22:07:28 +00:00
for i := 0; i < len(cfg.AddRepos); i++ {
cfg.AddRepos[i] = findVar.ReplaceAllStringFunc(cfg.AddRepos[i], replacer)
}
Expand env vars in Values/StringValues [#34]
2020-01-21 23:37:59 +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
func (cfg Config) logDebug() {
if cfg.KubeToken != "" {
cfg.KubeToken = "(redacted)"
}
fmt.Fprintf(cfg.Stderr, "Generated config: %+v\n", cfg)
}
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 (cfg *Config) deprecationWarn() {
for _, varname := range deprecatedVars {
_, barePresent := os.LookupEnv(varname)
_, prefixedPresent := os.LookupEnv("PLUGIN_" + varname)
if barePresent || prefixedPresent {
fmt.Fprintf(cfg.Stderr, "Warning: ignoring deprecated '%s' setting\n", strings.ToLower(varname))
}
}
}
Rough draft of aliased settings [#66]
2020-01-07 23:25:54 +00:00
Document the purpose of settingAliases [#95]
2020-05-22 22:35:43 +00:00
// settingAliases provides alternate environment variable names for certain settings, either because
// they were renamed during drone-helm3's lifetime or for backward-compatibility with the original
// drone-helm. Most config options don't need to be included here; adding them to the main Config
// struct is sufficient.
Rough draft of aliased settings [#66]
2020-01-07 23:25:54 +00:00
type settingAliases struct {
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
Command string `envconfig:"helm_command"`
AddRepos []string `envconfig:"helm_repos"`
APIServer string `envconfig:"api_server"`
ServiceAccount string `split_words:"true"`
Wait bool ``
Force bool ``
KubeToken string `envconfig:"kubernetes_token"`
Certificate string `envconfig:"kubernetes_certificate"`
Rough draft of aliased settings [#66]
2020-01-07 23:25:54 +00:00
}
Copy permalink