Commit graph

100 commits

Author SHA1 Message Date
Erin Call b1899dee56
Merge remote-tracking branch 'origin/master' into help-by-default 2019-12-26 12:23:14 -08:00
Erin Call 8f2d4bec49
Merge branch 'master' into testplan 2019-12-26 12:08:30 -08:00
Erin Call b2066961e1
Merge branch 'master' into kubeconfig-tests 2019-12-26 11:55:32 -08:00
Joachim Hill-Grannec 253a4465f8
Merge branch 'master' into config-fixup 2019-12-26 11:36:55 -08:00
Erin Call 6d28b7b28a
Return an error on unknown commands [#15]
I'm probably overthinking this--explicitly calling help is a strange and
unusual case--but it doesn't really hurt, so I'm going for it.
2019-12-26 11:29:33 -08:00
Joachim Hill-Grannec 81c4877a92
Merge branch 'master' into noncompulsory-certificate 2019-12-26 11:27:43 -08:00
Erin Call 34b9ec1c4c
Run the Help step by default [#15] 2019-12-26 10:47:42 -08:00
Erin Call 6b331fdf03
Check the validity of the kubeconfig template [#13]
It's a little tricky to find a balance between "brittle" and "thorough"
in this test--I'd like to verify that e.g. the certificate is in
clusters[0].cluster.certificate-authority-data, not at the root. On the
other hand, we can't actually show that it's a valid kubeconfig file
without actually *using* it, so there's a hard upper limit on the
strength of the assertions. I've settled on verifying that all the
settings make it into the file and the file is syntactically-valid yaml.
2019-12-25 10:11:14 -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 4ba1e694d9
Use a go-idiomatic constructor for helm.Config [#9] 2019-12-24 10:41:01 -08:00
Erin Call 10e7e7fee5
Document the Config struct's behavior correctly [#19] [#9] 2019-12-23 16:45:09 -08:00
Erin Call 285e9d98a4
Allow a configurable env var prefix [#19]
I'd like to keep Prefix's scope fairly limited, because it has potential
to spiral into something magnificently complex. You get one prefix
setting, it goes in `settings` not `environment`, end of feature.
2019-12-23 16:36:37 -08:00
Erin Call db87bd0507
Require no-error in config tests [#9] 2019-12-23 15:52:01 -08:00
Erin Call e2f53f3b08
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 15:34:08 -08:00
Erin Call c4c136b021
Do envconfig-loading in config.go (and test it!) [#9] 2019-12-23 15:10:00 -08:00
Erin Call ef4db923cd
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 14:06:05 -08:00
Erin Call ae9cb59a1f
No typo inthe helm.Config docs [#9] 2019-12-23 14:03:51 -08:00
Erin Call ad5baea3e6
Document helm.Config's struct fields more clearly [#9] 2019-12-23 14:02:46 -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 dc4ecb6b91
Allow an empty Certificate setting [#29]
I just plain misunderstood how kubernetes CAs worked!
2019-12-20 16:11:20 -08:00
Erin Call 197a377a82
Prod maintainers to keep the docs and code in sync [#8]
Offhand I don't see a way to ensure it programmatically, but I feel like
I should at least make an attempt.
2019-12-20 10:05:50 -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 7849b28532
Format the Delete struct less weirdly [#4]
I thought it was a golang style convention to put a blank line between
public and private struct fields, but apparently I imagined that.
2019-12-19 11:11:50 -08:00
Erin Call c033c8c45e
Format the Lint struct non-weirdly [#3]
I thought it was a golang style convention to put a blank line between
public and private struct fields, but apparently I imagined that.
2019-12-19 11:09:39 -08:00
Erin Call 30e1e3b99f
Assert that Lint.Prepare sets cmd.Stdout/Stderr [#3] 2019-12-19 10:26:33 -08:00
Erin Call b93917c857
Use better expectations in lint_test [#3]
The tests need to allow calls to Stdout/Stderr so they don't get
"Unexpected call" errors from gomock, but these tests aren't meant to
assert that the calls actually happened. Using .AnyTimes allows 0 or
more calls.
2019-12-19 10:21:11 -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 a21d6ad61f
Implement a Delete Step [#4] 2019-12-18 11:47:15 -08:00
Erin Call 84ac019838
Add the --namespace flag in Lint.Prepare [#3]
I don't know whether this is necessary; I'm just following drone-helm's
lead. At worst, helm will accept the flag, so it's at least *safe* to
include.
2019-12-18 10:38:33 -08:00
Erin Call 7e24756ad8
Instantiate a Lint when cfg.Command is "lint" [#3] 2019-12-17 17:14:39 -08:00
Erin Call a6a2d6e6a3
Require a nonempty chart in Lint.Prepare [#3] 2019-12-17 17:01:22 -08:00
Erin Call a6b7e06bd2
Implement the debug flag in lint [#3] 2019-12-17 17:01:18 -08:00
Erin Call 51800c18d7
Implement the various values flags in lint [#3] 2019-12-17 17:01:11 -08:00
Erin Call 991bbf97b4
Create a Lint step [#3]
Still need global flags and checks for mandatory settings, but the basic
functionality is there.
2019-12-17 17:01:06 -08:00
Erin Call aa04830600
Populate DryRun when building an Upgrade step 2019-12-17 09:23:44 -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
Erin Call e77f6842b9
Non-DI approach to the exec.Command mocking 2019-12-05 09:57:59 -08:00
Erin Call 990d1856d8
Very rough code that can helm install
The recommended way to test code that uses exec.Cmd involves setting up
a real exec.Cmd that invokes `go test` with additional arguments that
fire off a specially-constructed test that behaves the way the mocked-
out script would be expected to do. It's a sensible way to test exec.Cmd
itself, but for code that merely invokes it, I think it makes more sense
to use actual mocks.
2019-12-04 12:41:37 -08:00