Commit graph

9 commits

Author SHA1 Message Date
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 8d66036252
Brush all the lint off this code I wrote in a haze 2019-12-09 10:53:32 -08:00
Erin Call e3051ec72e
Replicate most of drone-helm's config 2019-12-09 09:58:42 -08:00