Commit graph

32 commits

Author SHA1 Message Date
Erin Call a21848484b
Initialize run.Configs in the NewSTEP functions [#67]
This fixes the run package's leaky abstraction; other packages no longer
need to know or care that run.Config even exists.

Note that since the various Steps now depend on having a non-nil pointer
to a run.Config, it's unsafe (or at least risky) to initialize them
directly. They should be created with their NewSTEPNAME functions. All
their fields are now private, to reflect this.
2020-01-17 10:55:12 -08:00
Erin Call 231138563c
Remove the cfg argument from Step.Execute [#67]
This is the first step toward removing run.Config entirely. InitKube was
the only Step that even used cfg in its Execute function; the rest just
discarded it.
2020-01-16 15:30:40 -08:00
Erin Call 21b9d32329
Remove the tiny helper functions from plan.go [#67]
Now that InitKube, AddRepo, and UpdateDependencies are initialized with
NewSTEPNAME functions, the helper functions in plan.go are
unnecessary--they do too little to be a useful abstraction, and they
aren't complex or frequently-used enough to be worth extracting.
2020-01-16 13:57:28 -08:00
Erin Call 588c7cb9f7
Initialize Steps with a NewSTEPNAME function [#67]
This seems to be be a more natural separation of concerns--the knowledge
of which config fields map to which parts of a Step belong to the Step,
not to the Plan.
2020-01-16 13:50:04 -08:00
Erin Call 16117eea2f
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 10:32:20 -08:00
Erin Call cfd8e33995
Use "backward-compatible", not "backwardS"
While writing docs in the previous commit, I noticed that we'd been
inconsistent in the naming scheme. Wikipedia's back-compat article
redirects from "backwards" to "backward", so I figure that's a
reasonable source of authority for which form to use.
2020-01-08 11:04:30 -08:00
Erin Call b6ba856c31
Pass CleanupOnFail to the Upgrade Step [#65]
I don't love the mismatch between the helm.Config field (CleanupOnFail)
and the setting name (cleanup_failed_upgrade). I do think the setting
name should contain "upgrade" since it's specific to the upgrade command,
but if I make the config field CleanupFailedUpgrade, it becomes the new
longest field name, and gofmt creates a bunch of churn. Is that a good
enough reason...?
2020-01-07 12:56:51 -08:00
Erin Call c8b4ad4c46
Pass an atomic_upgrade setting to the Upgrade step [#64] 2020-01-07 12:21:55 -08:00
Erin Call 8d8bcf78a7
Merge branch 'master' into keep-history 2020-01-02 13:26:53 -08:00
Erin Call 45428a2e25
Merge branch 'master' into keep-history 2020-01-02 12:29:32 -08:00
Erin Call 7b816ea257
Merge branch 'master' into values-arent-global 2020-01-02 12:29:15 -08:00
Erin Call 4330728215
Put step-specific config in those steps [#61]
This is just something that's been bugging me for a while--they're
specific to Lint and Upgrade, so that's where they belong.
2020-01-02 11:38:41 -08:00
Erin Call 3ae13d4b3c
Pass --strict to helm lint when so instructed [#28] 2020-01-02 11:25:13 -08:00
Erin Call 17724e7015
Pass --keep-history when so instructed [#24] 2020-01-02 10:58:58 -08:00
Erin Call 499ab6877f
Do repo error-checking in AddRepo.Prepare [#26] 2019-12-30 13:24:57 -08:00
Erin Call 48b6b3f5b3
Create AddRepo steps when there are repos to add [#26] 2019-12-30 11:57:19 -08:00
Erin Call 181165cc51
Call helm dependency update when so instructed [#25]
As with Lint, I have no idea whether the --namespace flag actually
matters here. I don't think it will hurt, though!
2019-12-27 15:06:32 -08:00
Erin Call d53a1ed942
Merge branch 'master' into testplan 2019-12-26 12:26:07 -08:00
Erin Call cb58b5a021
Phrase errors in Execute the same as in Prepare [#33] 2019-12-24 15:49:47 -08:00
Erin Call d86ac72529
Test Plan.Execute [#33] 2019-12-24 15:47:26 -08:00
Erin Call 52c9fb552c
Ensure the plan test mocks' expectations are met [#33] 2019-12-24 15:33:50 -08:00
Erin Call 08ddf5e27a
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 11:08:09 -08:00
Erin Call 4755f502b5
Always use the default kubeconfig file path [#20] 2019-12-23 12:47:16 -08:00
Erin Call 161960e55e
Rename Delete to Uninstall [#4]
Helm3 renamed its delete command to uninstall. We should still accept
helm_command=delete for drone-helm compatibility, but the internals
should use Helm's preferred name.
2019-12-19 15:04:33 -08:00
Erin Call 68a2c3cc86
Merge branch 'master' into helm-delete 2019-12-19 11:34:44 -08:00
Erin Call 5de156f823
Extract Plan's InitKube creation [#4]
It's `func initKube` rather than `var initKube = func` because initKube
is not meant to be returned by determineSteps.
2019-12-18 17:13:17 -08:00
Erin Call f398ee5724
Instantiate a Delete when appropriate [#4]
"delete" would be a more natural name for the instantiation function,
but that's a reserved word in golang.
2019-12-18 16:58:31 -08:00
Erin Call 7e24756ad8
Instantiate a Lint when cfg.Command is "lint" [#3] 2019-12-17 17:14:39 -08:00
Erin Call aa04830600
Populate DryRun when building an Upgrade step 2019-12-17 09:23:44 -08:00
Erin Call 13c663e906
Initialize kubernetes config on upgrade
This change revealed more about how the system needs to work, so there
are some supporting changes:

* helm.upgrade and helm.help are now vars rather than raw functions.
    This allows unit tests to target the "which step should we run"
    logic directly by comparing function pointers, rather than having to
    configure/prepare a fully-valid Plan and then infer the logic’s
    correctness based on the Plan’s state.
* configuration that's specific to kubeconfig initialization is now part
    of the InitKube struct rather than run.Config, since other steps
    shouldn’t need access to those settings (particularly the secrets).
* Step.Execute now receives a run.Config so it can log debug output.
2019-12-16 15:41:04 -08:00
Erin Call 4cbb4922fb
Implement the debug flag and help command
I'm vacillating about the choice to have separate Config structs in the
`helm` and `run` packages. I can't tell whether it's "good separation of
concerns" or "cumbersome and over-engineered." It seems appropriate at
the moment, though.
2019-12-10 15:33:50 -08:00
Erin Call e3051ec72e
Replicate most of drone-helm's config 2019-12-09 09:58:42 -08:00