Commit Graph

10 Commits

Author SHA1 Message Date
Joachim Hill-Grannec
253a4465f8 Merge branch 'master' into config-fixup 2019-12-26 11:36:55 -08:00
Erin Call
4755f502b5 Always use the default kubeconfig file path [#20] 2019-12-23 12:47:16 -08:00
Erin Call
3eb90651d1 Rough-draft upgrade settings documentation [#8] 2019-12-23 09:49:01 -08:00
Erin Call
1560c05100 Fail early if chart or release is missing 2019-12-16 17:02:56 -08:00
Erin Call
e4fa70239e Implement config flags for helm upgrade 2019-12-16 16:55:05 -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
Erin Call
238ede6f9e Actual drone-invokable helm commands 2019-12-05 14:35:25 -08:00