dentaku/woodpecker-helm3
1
0
Fork 0
Code Pull requests Releases Activity
woodpecker-helm3/README.md

96 lines
4 KiB
Markdown
Raw Normal View History

Make it so
2019-11-21 19:35:50 +00:00
# Drone plugin for Helm 3
Adding basic badges
2019-12-31 22:24:12 +00:00
[![Build Status](https://cloud.drone.io/api/badges/pelotech/drone-helm3/status.svg)](https://cloud.drone.io/pelotech/drone-helm3)
[![Go Report](https://goreportcard.com/badge/github.com/pelotech/drone-helm3)](https://goreportcard.com/report/github.com/pelotech/drone-helm3)
[![](https://images.microbadger.com/badges/image/pelotech/drone-helm3.svg)](https://microbadger.com/images/pelotech/drone-helm3 "Get your own image badge on microbadger.com")
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
This plugin provides an interface between [Drone](https://drone.io/) and [Helm 3](https://github.com/kubernetes/helm):
* Lint your charts
* Deploy your service
* Delete your service
Use "backward-compatible", not "backwardS" While writing docs in the previous commit, I noticed that we'd been inconsistent in the naming scheme. Wikipedia's back-compat article redirects from "backwards" to "backward", so I figure that's a reasonable source of authority for which form to use.
2020-01-08 19:04:30 +00:00
The plugin is inpsired by [drone-helm](https://github.com/ipedrazas/drone-helm), which fills the same role for Helm 2. It provides a comparable feature-set and the configuration settings are backward-compatible.
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
## Example configuration
Document parameters in a single markdown file [#8] I was unhappy with the comments-in-yaml approach; it required duplicating a lot of information and it was hard to find a balance between "usefully thorough" and "readably concise.""
2019-12-24 22:36:39 +00:00
The examples below give a minimal and sufficient configuration for each use-case. For a full description of each command's settings, see [docs/parameter_reference.md](docs/parameter_reference.md).
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
### Linting
```yaml
steps:
- name: lint
image: pelotech/drone-helm3
settings:
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
mode: lint
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
chart: ./
```
Use "installation" rather than "deployment" [#8] "deploy" matches my mental model of what helm does, but "install" matches helm's own terminology more closely.
2019-12-24 23:22:25 +00:00
### Installation
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
```yaml
steps:
- name: deploy
image: pelotech/drone-helm3
settings:
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
mode: upgrade
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
chart: ./
release: my-project
environment:
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
KUBE_API_SERVER: https://my.kubernetes.installation/clusters/a-1234
KUBE_TOKEN:
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
from_secret: kubernetes_token
```
Use "installation" rather than "deployment" [#8] "deploy" matches my mental model of what helm does, but "install" matches helm's own terminology more closely.
2019-12-24 23:22:25 +00:00
### Uninstallation
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
```yaml
steps:
Rename "delete" to "uninstall" [#8] Helm 3 renamed the command, and I didn't realize it until just now. See also 161960e, where it was renamed in the code.
2019-12-19 23:23:13 +00:00
- name: uninstall
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
image: pelotech/drone-helm3
settings:
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
mode: uninstall
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
release: my-project
environment:
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
KUBE_API_SERVER: https://my.kubernetes.installation/clusters/a-1234
KUBE_TOKEN:
First draft of a useful README [#8]
2019-12-19 22:53:53 +00:00
from_secret: kubernetes_token
```
## Upgrading from drone-helm
Use "backward-compatible", not "backwardS" While writing docs in the previous commit, I noticed that we'd been inconsistent in the naming scheme. Wikipedia's back-compat article redirects from "backwards" to "backward", so I figure that's a reasonable source of authority for which form to use.
2020-01-08 19:04:30 +00:00
drone-helm3 is largely backward-compatible with drone-helm. There are some known differences:
Note a backwards-incompatibility in the README [#8] This probably isn't going to bite anyone, but it's technically possible, and it doesn't hurt to mention it.
2019-12-24 23:25:44 +00:00
Update README.md Co-Authored-By: Erin Call <hello@erincall.com>
2019-12-31 22:54:46 +00:00
* You'll need to migrate the deployments in the cluster [helm-v2-to-helm-v3](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/).
Mention that EKS isn't currently supported [#5] We'd like to support it eventually, but the current state of affairs doesn't justify the effort. Also removed some vestigial code that was copy-pasta from the kubeconfig in drone-helm.
2019-12-27 18:49:22 +00:00
* EKS is not supported. See [#5](https://github.com/pelotech/drone-helm3/issues/5) for more information.
Remove support for the prefix setting [#48] The setting isn't necessary with modern versions of Drone, and it creates a lot of edge-cases. The use-case doesn't justify the added complexity.
2019-12-31 17:28:42 +00:00
* The `prefix` setting is no longer supported. If you were relying on the `prefix` setting with `secrets: [...]`, you'll need to switch to the `from_secret` syntax.
Pass --keep-history when so instructed [#24]
2020-01-02 18:58:58 +00:00
* During uninstallations, the release history is purged by default. Use `keep_history: true` to return to the old behavior.
Emit warnings about deprecated settings [#10] These aren't an error case--the plugin will work just fine--but users should be aware they (the settings) aren't being respected.
2019-12-31 18:03:53 +00:00
* Several settings no longer have any effect. The plugin will produce warnings if any of these are present:
Note a backwards-incompatibility in the README [#8] This probably isn't going to bite anyone, but it's technically possible, and it doesn't hurt to mention it.
2019-12-24 23:25:44 +00:00
* `purge` -- this is the default behavior in Helm 3
* `recreate_pods`
* `tiller_ns`
* `upgrade`
* `canary_image`
* `client_only`
* `stable_repo_url`
Default to the canonical setting names [#66] The goal with these changes was to give users a clearer, more readable interface, so we should present that interface up front and only document the aliases as a backward-compatibility option. I've renamed the envconfig tags to reflect the switch, but I left the actual field names the same. I think they're sufficiently meaningful inside the code, and leaving them unchanged avoids making a bunch of churn in the rest of the code.
2020-01-08 18:45:53 +00:00
* Several settings have been renamed, to clarify their purpose and provide a more consistent naming scheme. For backward-compatibility, the old names are still available as aliases. If the old and new names are both present, the updated form takes priority. Conflicting settings will make your `.drone.yml` harder to understand, so we recommend updating to the new names:
* `helm_command` is now `mode`
° `helm_repos` is now `add_repos`
* `api_server` is now `kube_api_server`
* `service_account` is now `kube_service_account`
* `kubernetes_token` is now `kube_token`
* `kubernetes_certificate` is now `kube_certificate`
* `wait` is now `wait_for_upgrade`
* `force` is now `force_upgrade`
Note a backwards-incompatibility in the README [#8] This probably isn't going to bite anyone, but it's technically possible, and it doesn't hurt to mention it.
2019-12-24 23:25:44 +00:00
Since helm 3 does not require Tiller, we also recommend switching to a service account with less-expansive permissions.
Directions on how to setup custom build of images till PR gets merged
2019-12-31 19:19:56 +00:00
add link to contributing
2019-12-31 19:48:21 +00:00
### [Contributing](docs/contributing.md)
Directions on how to setup custom build of images till PR gets merged
2019-12-31 19:19:56 +00:00
This repo is setup in a way that if you enable a personal drone server to build your fork it will
build and publish your image (makes it easier to test PRs and use the image till the contributions get merged)
Merge branch 'master' into no-eks-support
2020-01-01 17:09:01 +00:00
Directions on how to setup custom build of images till PR gets merged
2019-12-31 19:19:56 +00:00
* Build local ```DRONE_REPO_OWNER=josmo DRONE_REPO_NAME=drone-ecs drone exec```
Merge branch 'master' into no-eks-support
2020-01-01 17:09:01 +00:00
* on your server (or cloud.drone.io) just make sure you have DOCKER_USERNAME, DOCKER_PASSWORD, and PLUGIN_REPO set as secrets
Copy permalink