woodpecker-helm3/README.md

# Drone plugin for Helm 3

TODO:

* [x] Make a `.drone.yml` that's sufficient for building an image
* [x] Make a `Dockerfile` that's sufficient for launching the built image
* [x] Make `cmd/drone-helm/main.go` actually invoke `helm`
* [x] Make `golint` part of the build process (and make it pass)
* [x] Implement debug output
* [x] Flesh out `helm upgrade` until it's capable of working
* [ ] Implement config settings for `upgrade`
* [ ] Implement `helm lint`
* [ ] Implement `helm delete`
* [ ] Look for command-line flags added in helm3; implement them
* [ ] EKS support
* [ ] Dotenv support
* [ ] Example drone config in this README
* [ ] Change `.drone.yml` to use a real docker registry

Nice-to-haves:

* [ ] Cleanup() method on Steps to close open filehandles, etc.
* [ ] Replace `fmt.Printf` with an actual logger
* [ ] Replace `fmt.Errorf` with `github.com/pkg/errors.Wrap`, since the built-in `Unwrap` doesn't work the way `Cause` does
* [ ] Deprecation warnings if there are environment variables that aren't applicable in helm3
Make it so 2019-11-21 19:35:50 +00:00			`# Drone plugin for Helm 3`

Initial config for building the plugin itself 2019-12-03 17:50:15 +00:00			`TODO:`

			* [x] Make a `.drone.yml` that's sufficient for building an image
			* [x] Make a `Dockerfile` that's sufficient for launching the built image
Replicate most of drone-helm's config 2019-12-09 17:56:02 +00:00			* [x] Make `cmd/drone-helm/main.go` actually invoke `helm`
Brush all the lint off this code I wrote in a haze 2019-12-09 18:52:41 +00:00			* [x] Make `golint` part of the build process (and make it pass)
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 00:25:47 +00:00			`* [x] Implement debug output`
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-12 18:20:11 +00:00			* [x] Flesh out `helm upgrade` until it's capable of working
Further todo list 2019-12-09 18:53:42 +00:00			* [ ] Implement config settings for `upgrade`
Replicate most of drone-helm's config 2019-12-09 17:56:02 +00:00			* [ ] Implement `helm lint`
			* [ ] Implement `helm delete`
More TODOs in the README 2019-12-17 01:07:33 +00:00			`* [ ] Look for command-line flags added in helm3; implement them`
Replicate most of drone-helm's config 2019-12-09 17:56:02 +00:00			`* [ ] EKS support`
More TODOs in the README 2019-12-17 01:07:33 +00:00			`* [ ] Dotenv support`
			`* [ ] Example drone config in this README`
Initial config for building the plugin itself 2019-12-03 17:50:15 +00:00			* [ ] Change `.drone.yml` to use a real docker registry
More TODOs in the README 2019-12-17 01:07:33 +00:00
			`Nice-to-haves:`

			`* [ ] Cleanup() method on Steps to close open filehandles, etc.`
			* [ ] Replace `fmt.Printf` with an actual logger
			* [ ] Replace `fmt.Errorf` with `github.com/pkg/errors.Wrap`, since the built-in `Unwrap` doesn't work the way `Cause` does
			`* [ ] Deprecation warnings if there are environment variables that aren't applicable in helm3`