From 4cd369b051b3e7fe646547d6dc085bfcd775a45e Mon Sep 17 00:00:00 2001 From: Erin Call Date: Wed, 25 Dec 2019 10:50:20 -0800 Subject: [PATCH 1/7] Auto-assign rewiewers with a CODEOWNERS [#12] --- .github/CODEOWNERS | 1 + 1 file changed, 1 insertion(+) create mode 100644 .github/CODEOWNERS diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 0000000..378c620 --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1 @@ +* @erincall @grinnellian @kav @josmo From 4f549ddf2a0e9944f235cc7aa6f3f81271f225f2 Mon Sep 17 00:00:00 2001 From: Erin Call Date: Wed, 25 Dec 2019 11:20:14 -0800 Subject: [PATCH 2/7] Pre-populate pull request bodies with a template [#12] Note that as of this writing, docs/parameter_reference.md (and required- params documentation in README.md) doesn't actually exist; I created it in ef66bc0 but that commit hasn't been merged yet. --- .github/pull_request_template.md | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 .github/pull_request_template.md diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000..8985c6a --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,8 @@ +**Please replace this line with "fixes #ISSUE_NUMBER" (or "relates to #ISSUE_NUMBER", if it is not a complete fix)** + +Pre-merge checklist: + +* [ ] Code changes have tests +* [ ] Any changes to the config are documented in `docs/parameter_reference.md` +* [ ] Any new _required_ config is documented in `README.md` +* [ ] Any large changes have been verified by running a Drone job From 1a70a626ea1d81569e85f508497c0eda21928738 Mon Sep 17 00:00:00 2001 From: Erin Call Date: Wed, 25 Dec 2019 11:46:56 -0800 Subject: [PATCH 3/7] Use the Contributor Covenant code of conduct [#12] --- CODE_OF_CONDUCT.md | 76 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 CODE_OF_CONDUCT.md diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..cc02111 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,76 @@ +# Contributor Covenant Code of Conduct + +## Our Pledge + +In the interest of fostering an open and welcoming environment, we as +contributors and maintainers pledge to making participation in our project and +our community a harassment-free experience for everyone, regardless of age, body +size, disability, ethnicity, sex characteristics, gender identity and expression, +level of experience, education, socio-economic status, nationality, personal +appearance, race, religion, or sexual identity and orientation. + +## Our Standards + +Examples of behavior that contributes to creating a positive environment +include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or + advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic + address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a + professional setting + +## Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable +behavior and are expected to take appropriate and fair corrective action in +response to any instances of unacceptable behavior. + +Project maintainers have the right and responsibility to remove, edit, or +reject comments, commits, code, wiki edits, issues, and other contributions +that are not aligned to this Code of Conduct, or to ban temporarily or +permanently any contributor for other behaviors that they deem inappropriate, +threatening, offensive, or harmful. + +## Scope + +This Code of Conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. Examples of +representing a project or community include using an official project e-mail +address, posting via an official social media account, or acting as an appointed +representative at an online or offline event. Representation of a project may be +further defined and clarified by project maintainers. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by contacting the project team at [workwithus@pelo.tech](mailto:workwithus@pelo.tech). All +complaints will be reviewed and investigated and will result in a response that +is deemed necessary and appropriate to the circumstances. The project team is +obligated to maintain confidentiality with regard to the reporter of an incident. +Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good +faith may face temporary or permanent repercussions as determined by other +members of the project's leadership. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, +available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html + +[homepage]: https://www.contributor-covenant.org + +For answers to common questions about this code of conduct, see +https://www.contributor-covenant.org/faq From f00f6a63292e246f7177fec3b7cd543de2354f48 Mon Sep 17 00:00:00 2001 From: Erin Call Date: Wed, 25 Dec 2019 12:03:36 -0800 Subject: [PATCH 4/7] Encourage good issues with issue templates [#12] I've never used github's new multiple-option issue templates before! I'm excited to see them in action :) --- .github/ISSUE_TEMPLATE/bug_report.md | 17 +++++++++++++++++ .github/ISSUE_TEMPLATE/feature_request.md | 14 ++++++++++++++ 2 files changed, 31 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/bug_report.md create mode 100644 .github/ISSUE_TEMPLATE/feature_request.md diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 0000000..aadc390 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,17 @@ +--- +name: Bug report +about: Unexpected or broken behavior +title: '' +labels: bug +assignees: '' + +--- + +**What I tried to do:** + + +**What happened:** + + +**More info:** + diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md new file mode 100644 index 0000000..40932a7 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -0,0 +1,14 @@ +--- +name: Feature request +about: Suggest a new feature +title: '' +labels: enhancement +assignees: '' + +--- + +**The problem I'm trying to solve:** + + +**How I imagine it working:** + From a71bba71fdf0fc56527ba5066247792d2f36fd82 Mon Sep 17 00:00:00 2001 From: Erin Call Date: Wed, 25 Dec 2019 16:08:29 -0800 Subject: [PATCH 5/7] Give contributors some maybe-adequate information [#12] I honestly have no idea how useful this document is, but it's probably better than nothing? --- .drone.yml | 9 +++++++++ docs/contributing.md | 48 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 docs/contributing.md diff --git a/.drone.yml b/.drone.yml index 66984fa..08bcf70 100644 --- a/.drone.yml +++ b/.drone.yml @@ -30,3 +30,12 @@ steps: dockerfile: Dockerfile when: event: [ tag, push ] + + # Example configuration for publishing to a local registry for testing. + # - name: publish_locally + # image: plugins/docker + # settings: + # dockerfile: Dockerfile + # insecure: true + # registry: 0.0.0.0:5000 + # repo: 0.0.0.0:5000/drone-helm3 diff --git a/docs/contributing.md b/docs/contributing.md new file mode 100644 index 0000000..ef70d84 --- /dev/null +++ b/docs/contributing.md @@ -0,0 +1,48 @@ +# Contributing to drone-helm3 + +We're glad you're interested in contributing! Here are some guidelines that will help make sure everyone has a good experience: + +## Submitting a patch + +Before you start working on a change, please make sure there's an associated issue. It doesn't need to be thoroughly scrutinized and dissected, but it needs to exist. + +Please put the relevant issue number in the first line of your commit messages, e.g. `vorpalize the frabjulator [#42]`. Branch names do not need issue numbers, but feel free to include them if you like. + +We encourage you to follow [the guidelines in Pro Git](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project#_commit_guidelines) when making commits. In short: + +* Commit early and commit often. +* Make the first line of the commit message concise--no more than 50 characters or so. +* Make the rest of the commit message verbose--information about _why_ you did what you did is particularly helpful. + +Once you're satisfied with your work, send us a pull request. If you'd like, you can send the pull request _before_ you're satisfied with your work; just be sure to mark the PR a draft or put `[WIP]` in the title. + +## How to run the tests + +We use `go test`, `go vet`, and `golint`: + +``` +go test ./cmd/... ./internal/... +go vet ./cmd/... ./internal/... +golint -set_exit_status ./cmd/... ./internal/... +``` + +If you have [the Drone cli tool](https://docs.drone.io/cli/install/) installed, you can also use `drone exec --include test --include lint`. + +## Using the plugin locally + +The internal tests can't test drone-helm3's integration with drone and helm themselves. However, you can build and run a local image to test a change end-to-end. + +You will need: + +* A Docker image registry. See [docs.docker.com/registry/](https://docs.docker.com/registry/) for information on standing up a local registry. +* You will also need [the Drone cli tool](https://docs.drone.io/cli/install/). +* A fixture repo--a repo with a `.drone.yml` and a helm chart. +* Access to a kubernetes cluster. + +Once you have a local registry, uncomment the `publish_locally` step in `.drone.yml` and replace the `0.0.0.0`s with your computer's local IP address. + +Now you can run `drone exec --include test --include lint --include publish_locally` to build an image and publish it to your local registry. + +Finally, configure your fixture repo to use the locally-published image, e.g. `image: 192.168.0.1:5000/drone-helm3`. + +Now you can use `drone exec` in the fixture repo to verify your changes. From 232bb5eb960a2220baef8d78df02814c657e8a13 Mon Sep 17 00:00:00 2001 From: Erin Call Date: Thu, 26 Dec 2019 13:03:53 -0800 Subject: [PATCH 6/7] Rely on the PR template for docs/code consistency [#12] These comments were a reasonable attempt at ensuring the documentation matched reality, but the checkbox in the pull request template is much more likely to produce results. --- internal/helm/plan.go | 1 - internal/run/lint.go | 2 -- internal/run/upgrade.go | 2 -- 3 files changed, 5 deletions(-) diff --git a/internal/helm/plan.go b/internal/helm/plan.go index 54de589..e6c8721 100644 --- a/internal/helm/plan.go +++ b/internal/helm/plan.go @@ -69,7 +69,6 @@ func determineSteps(cfg Config) *func(Config) []Step { return &help default: switch cfg.DroneEvent { - // Note: These events are documented in docs/upgrade_settings.yml. Any changes here should be reflected there. case "push", "tag", "deployment", "pull_request", "promote", "rollback": return &upgrade case "delete": diff --git a/internal/run/lint.go b/internal/run/lint.go index 1993b49..e2843ca 100644 --- a/internal/run/lint.go +++ b/internal/run/lint.go @@ -16,8 +16,6 @@ func (l *Lint) Execute(_ Config) error { } // Prepare gets the Lint ready to execute. -// Note: mandatory settings are documented in README.md, and the full list of settings is in docs/lint_settings.yml. -// Any additions or deletions here should be reflected there. func (l *Lint) Prepare(cfg Config) error { if l.Chart == "" { return fmt.Errorf("chart is required") diff --git a/internal/run/upgrade.go b/internal/run/upgrade.go index fc561aa..dd50527 100644 --- a/internal/run/upgrade.go +++ b/internal/run/upgrade.go @@ -25,8 +25,6 @@ func (u *Upgrade) Execute(_ Config) error { } // Prepare gets the Upgrade ready to execute. -// Note: mandatory settings are documented in README.md, and the full list of settings is in docs/upgrade_settings.yml. -// Any additions or deletions here should be reflected there. func (u *Upgrade) Prepare(cfg Config) error { if u.Chart == "" { return fmt.Errorf("chart is required") From 24060c18fccf9036d4378a64d2a1f1928f3d56e9 Mon Sep 17 00:00:00 2001 From: Erin Call Date: Thu, 26 Dec 2019 15:21:01 -0800 Subject: [PATCH 7/7] Provide better e2e-testing instructions [#12] The "get a kubernetes cluster" part could use some outfleshing, but this is certainly more straightforward than it was before. --- .drone.yml | 9 --------- .gitignore | 2 ++ docs/contributing.md | 24 ++++++++++++------------ docs/example.secrets | 3 +++ 4 files changed, 17 insertions(+), 21 deletions(-) create mode 100644 docs/example.secrets diff --git a/.drone.yml b/.drone.yml index 08bcf70..66984fa 100644 --- a/.drone.yml +++ b/.drone.yml @@ -30,12 +30,3 @@ steps: dockerfile: Dockerfile when: event: [ tag, push ] - - # Example configuration for publishing to a local registry for testing. - # - name: publish_locally - # image: plugins/docker - # settings: - # dockerfile: Dockerfile - # insecure: true - # registry: 0.0.0.0:5000 - # repo: 0.0.0.0:5000/drone-helm3 diff --git a/.gitignore b/.gitignore index 66fd13c..feb6e6e 100644 --- a/.gitignore +++ b/.gitignore @@ -13,3 +13,5 @@ # Dependency directories (remove the comment below to include it) # vendor/ +.env +.secrets diff --git a/docs/contributing.md b/docs/contributing.md index ef70d84..dae4001 100644 --- a/docs/contributing.md +++ b/docs/contributing.md @@ -28,21 +28,21 @@ golint -set_exit_status ./cmd/... ./internal/... If you have [the Drone cli tool](https://docs.drone.io/cli/install/) installed, you can also use `drone exec --include test --include lint`. -## Using the plugin locally +## Testing the plugin end-to-end -The internal tests can't test drone-helm3's integration with drone and helm themselves. However, you can build and run a local image to test a change end-to-end. +Although we aim to make the internal tests as thorough as possible, they can't test drone-helm3's integration with drone and helm themselves. However, you can test a change manually by building an image and running it with a fixture repository. You will need: -* A Docker image registry. See [docs.docker.com/registry/](https://docs.docker.com/registry/) for information on standing up a local registry. -* You will also need [the Drone cli tool](https://docs.drone.io/cli/install/). -* A fixture repo--a repo with a `.drone.yml` and a helm chart. -* Access to a kubernetes cluster. +* Access to a docker image registry. This document assumes you'll use [Docker Hub](https://hub.docker.com). +* [The Drone cli tool](https://docs.drone.io/cli/install/). +* A fixture repository--a directory with a `.drone.yml` and a helm chart. If you don't have one handy, try adding a `.drone.yml` to a chart from [Helm's "stable" repository](https://github.com/helm/charts/tree/master/stable/). +* Access to a kubernetes cluster (unless `lint` or `dry_run` is sufficient for your purposes). -Once you have a local registry, uncomment the `publish_locally` step in `.drone.yml` and replace the `0.0.0.0`s with your computer's local IP address. +Once you have what you need, you can publish and consume an image with your changes: -Now you can run `drone exec --include test --include lint --include publish_locally` to build an image and publish it to your local registry. - -Finally, configure your fixture repo to use the locally-published image, e.g. `image: 192.168.0.1:5000/drone-helm3`. - -Now you can use `drone exec` in the fixture repo to verify your changes. +1. [Create a repository on Docker Hub](https://hub.docker.com/repository/create). This document assumes you've called it drone-helm3-testing. +1. Create a `.secrets` file with your docker credentials (see [example.secrets](./example.secrets) for an example). While you can use your Docker Hub password, it's better to [generate an access token](https://hub.docker.com/settings/security) and use that instead. +1. Use Drone to build and publish an image with your changes: `drone exec --secret-file ./secrets --event push` +1. In the `.drone.yml` of your fixture repository, set the `image` for each relevant stanza to `your_dockerhub_username/drone-helm3-testing` +1. Use `drone exec` in the fixture repo to verify your changes. diff --git a/docs/example.secrets b/docs/example.secrets new file mode 100644 index 0000000..c9c99b7 --- /dev/null +++ b/docs/example.secrets @@ -0,0 +1,3 @@ +DOCKER_PASSWORD=your_access_token +DOCKER_USERNAME=your_dockerhub_username +PLUGIN_REPO=your_dockerhub_username/drone-helm3-testing