Commit graph

20 commits

Author SHA1 Message Date
Colin Hoglund eeccfdd143 fix test 2022-08-16 11:42:02 -07:00
Colin Hoglund 8d450bbf7d DEVOPS-2496 add max history setting (#12)
* add history_max setting

* update docs

* use suite for env test
2022-08-16 11:37:13 -07:00
George Kaz e482a144c1 add skip-crds flag support
Signed-off-by: George Kaz <egeorgekaz@gmail.com>
2021-07-20 19:26:00 +01:00
Erin Call 18313eeb5c
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 15:40:36 -08:00
Erin Call fcddc6e077
Merge branch 'master' into godiomaticity 2020-01-20 11:24:28 -08:00
Erin Call c38537ac32
Pass --ca-file to helm upgrade when applicable [#74] 2020-01-20 10:48:21 -08:00
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 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 8c6c6fbfa5
CleanupOnFail option for the upgrade Step [#65] 2020-01-07 12:53:55 -08:00
Erin Call 971e3f17cb
Atomic option for the Upgrade step [#64] 2020-01-07 12:17:54 -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 4755f502b5
Always use the default kubeconfig file path [#20] 2019-12-23 12:47:16 -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