Commit graph

34 commits

Author SHA1 Message Date
Erin Call 5e2f2f3dc6
First draft of a useful README [#8] 2019-12-19 14:53:53 -08:00
Joachim Hill-Grannec 6452a01c82
update drone.yml to publish to docker hub 2019-12-19 13:38:04 -08:00
Erin Call 6acad85bed
Merge pull request #18 from pelotech/helm-lint
Run the `helm lint` command when HELM_COMMAND=lint
2019-12-19 11:33:01 -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 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 9b3616613b
Merge pull request #17 from pelotech/no-todos
Remove the TODO list from README.md
2019-12-18 08:09:38 -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 f3039ee35d
Merge branch 'master' into no-todos 2019-12-17 15:35:28 -08:00
Erin Call 09e4869b2c
Merge pull request #2 from pelotech/flesh-out-upgrade
Build out the rest of the upgrade Step
2019-12-17 15:34:08 -08:00
Erin Call c641c1a326
Remove the TODO list from README.md
Everything on the checklist has been converted to a github issue, so
it's redundant.
2019-12-17 15:23:42 -08:00
Erin Call aa04830600
Populate DryRun when building an Upgrade step 2019-12-17 09:23:44 -08:00
Erin Call c585d8a22b
More TODOs in the README 2019-12-16 17:07:33 -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 c08b2035a8
Merge pull request #1 from pelotech/assorted-cleanups
Assorted cleanups
2019-12-16 15:48:27 -08:00
Erin Call 9797f5c8a2
Non-0 exit status on error 2019-12-16 15:46:37 -08:00
Erin Call 173cf374f9
Run linting on an image with golint preinstalled
Running `go get` adds a line to `go.mod` every time, so using a
preinstalled golint avoids churn.
2019-12-16 15:44:46 -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 446c6f1761
Run golint during drone builds 2019-12-09 15:27:56 -08:00
Erin Call dad866582a
Further todo list 2019-12-09 10:53:42 -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
Erin Call ba75a9b1d8
Initial config for building the plugin itself 2019-12-03 09:50:15 -08:00
Erin Call 6b121047e1
Make it so 2019-11-21 11:35:50 -08:00