From 04d700ba6252ce88110c00db4b5eef72e840bbf5 Mon Sep 17 00:00:00 2001 From: Eric Stroczynski Date: Tue, 15 Sep 2020 12:32:06 -0700 Subject: [PATCH] docs/contribution-guidelines: improve formatting, remove specifics of tests --- .../en/docs/contribution-guidelines/_index.md | 3 +- .../developer-guide.md | 108 ++++++----------- .../contribution-guidelines/documentation.md | 44 +++++++ .../contribution-guidelines/local-changes.md | 90 -------------- .../contribution-guidelines/local-docs.md | 42 ------- .../{release.md => releasing.md} | 1 + .../reporting-issues.md | 3 +- .../docs/contribution-guidelines/testing.md | 47 ++++++++ .../contribution-guidelines/testing/_index.md | 4 - .../testing/running-the-tests.md | 114 ------------------ .../testing/travis-build.md | 73 ----------- 11 files changed, 134 insertions(+), 395 deletions(-) create mode 100644 website/content/en/docs/contribution-guidelines/documentation.md delete mode 100644 website/content/en/docs/contribution-guidelines/local-changes.md delete mode 100644 website/content/en/docs/contribution-guidelines/local-docs.md rename website/content/en/docs/contribution-guidelines/{release.md => releasing.md} (99%) create mode 100644 website/content/en/docs/contribution-guidelines/testing.md delete mode 100644 website/content/en/docs/contribution-guidelines/testing/_index.md delete mode 100644 website/content/en/docs/contribution-guidelines/testing/running-the-tests.md delete mode 100644 website/content/en/docs/contribution-guidelines/testing/travis-build.md diff --git a/website/content/en/docs/contribution-guidelines/_index.md b/website/content/en/docs/contribution-guidelines/_index.md index 0bd9e9cfe0..d0fed2990e 100644 --- a/website/content/en/docs/contribution-guidelines/_index.md +++ b/website/content/en/docs/contribution-guidelines/_index.md @@ -1,7 +1,6 @@ --- title: How to Contribute -linkTitle: Contribution Guidelines +linkTitle: Contribution Guide weight: 9 description: Contribute to Operator SDK --- - diff --git a/website/content/en/docs/contribution-guidelines/developer-guide.md b/website/content/en/docs/contribution-guidelines/developer-guide.md index 6b79d2849e..7a64a04874 100644 --- a/website/content/en/docs/contribution-guidelines/developer-guide.md +++ b/website/content/en/docs/contribution-guidelines/developer-guide.md @@ -1,97 +1,67 @@ --- -title: Development Environment -weight: 30 +title: Development +linkTitle: Development +weight: 1 --- -This document explains how to setup your dev environment. +## Installation + +### Prerequisites -## Prerequisites - [git][git-tool] -- [go][go-tool] version v1.13+ +- [go][go-tool] v1.13+ -## Download Operator SDK +### Download Operator SDK -Go to the [Operator SDK repo][repo-sdk] and follow the [fork guide][fork-guide] to fork, clone, and setup the local operator-sdk repository. +Go to the [operator-sdk repo][repo-sdk] and follow the [fork guide][fork-guide] to fork and set up a local repository. -## Build the Operator SDK CLI +### Build the Operator SDK CLI Build the Operator SDK CLI `operator-sdk` binary: ```sh -$ make install +make install ``` -Then, now you are able to test and use the operator-sdk build using the source code. - ## Testing -The SDK includes many tests that are run as part of CI. -To build the binary and run all tests (assuming you have a correctly configured environment), -you can simple run: - -```sh -$ make test-ci -``` - -If you simply want to run the unit tests, you can run: - -```sh -$ make test -``` - -For more information on running testing and correctly configuring your environment, -refer to the [`Running the Tests Locally`][running-the-tests] document. To incorporate code changes in your development environment see the [`Testing changes Locally`][testing-changes-locally] document. - -To run the lint checks done in the CI locally, run: - -```sh -$ make lint -``` - -**NOTE** Note that for it is required to install `golangci-lint` locally. For more info see its [doc](https://github.com/golangci/golangci-lint#install) - -## How the operator-sdk binaries are built - -In the release process, the script [.release.sh][release-sh] is executed and it will call the [makefile][makefile] target [make release](https://github.com/operator-framework/operator-sdk/blob/master/Makefile#L113). To know more about the release process, see the [doc][release-doc] also see [operator-sdk releases](https://github.com/operator-framework/operator-sdk/releases). - -**NOTE** The Deploy stage (configured in [.travis.yml ][travis]) builds also execute the same [makefile][makefile] targets. This stage is executed against the master branch when a Pull Request is merged. - -## How to test the build of operator-sdk binaries - -Follow these steps to execute the Travis `Deploy` stage against your branch to demonstrate that the merge build will complete as expected. +See the [testing][dev-testing] and [documentation][dev-docs] guides for more information. -- Enable the Travis in your fork repository. For more info see [`To get started with Travis CI using GitHub`](https://docs.travis-ci.com/user/tutorial/#to-get-started-with-travis-ci-using-github) -- Create image repos in quay (or another registry that supports multi-arch images) for ansible, helm, and scorecard proxy. For each image type, you need repos for the manifest list and one for each architecture (e.g. `ansible-operator`, `ansible-operator-amd64`, `ansible-operator-s390x`, etc.) +## Releasing -**NOTE** Be sure to make each repository public. +See the [release guide][dev-release] for more information. -- Set the following environment variables in the Travis settings for your fork: +## Continuous Integration (CI) - - `ANSIBLE_IMAGE` docker image name (e.g. `quay.io/joelanford/ansible-operator`) - - `HELM_IMAGE` same as above, but for helm - - `SCORECARD_PROXY_IMAGE` same as above, but for scorecard proxy - - `DOCKER_USERNAME` credentials for your repo - - `DOCKER_PASSWORD` credentials for your repo - - `DOCKER_CLI_EXPERIMENTAL` set to `enabled` - - `COVERALLS_TOKEN` token to integrate the project with `https://coveralls.io/`. So, enable your fork in `https://coveralls.io/` and generate a token to allow it. +The operator-sdk repo uses [Travis CI][travis] to test each pull request and build images for both master commits +and releases. You can alter these processes by modifying this [`.travis.yml`][travis.yml] config file. -- Make a commit with `[travis deploy]` in the commit message on the branch with the changes. -- Check the travis build for your branch in your fork (not the PR build in the operator-sdk repo, since we don't allow PRs to build images in the `operator-framework` quay repo.) +### Testing builds with new architectures -**NOTE** Post a link in the Pull Request to the Travis build page showing successful `Deploy` and `Deploy multi-arch manifest lists` stages with your changes. +Follow these steps to execute the Travis `Deploy` stage against your branch +to demonstrate that the merge build will complete as expected. -See the project [README][sdk-readme] for more details. +- Enable Travis in your fork repository. See [this guide][travis-setup] for more information. +- Create public image repos for each image built by `make image-build`; make sure the registry used supports +multi-arch images, like quay.io. + - For each image type, you need one repo for the manifest list and one for each architecture being tested. +- Set each image variable (that ends in `_IMAGE`, not `_BASE_IMAGE`) found in the Makefile +as an environment variable in `.travis.yml`, ex. `export SCORECARD_TEST_IMAGE=//scorecard-test:latest` +- Create a PR with your configuration changes to _your_ fork, with the first commit message containing +`[travis deploy]`. + - This commit is only for testing on your fork's PR. This commit/message should not be present in an operator-sdk + repo PR. +- Ensure the image builds for that PR pass. +- Create a PR to the operator-sdk repo with a description containing a link to the Travis build page +showing a successful deployment stage with your changes. [git-tool]:https://git-scm.com/downloads [go-tool]:https://golang.org/dl/ [repo-sdk]:https://github.com/operator-framework/operator-sdk [fork-guide]:https://help.github.com/en/articles/fork-a-repo -[docker-tool]:https://docs.docker.com/install/ -[kubectl-tool]:https://kubernetes.io/docs/tasks/tools/install-kubectl/ -[sdk-readme]: https://github.com/operator-framework/operator-sdk/blob/master/README.md -[running-the-tests]: ../testing/running-the-tests -[testing-changes-locally]: ../local-changes -[makefile]: https://github.com/operator-framework/operator-sdk/blob/master/Makefile -[travis]: https://github.com/operator-framework/operator-sdk/blob/master/.travis.yml -[release-sh]: https://github.com/operator-framework/operator-sdk/blob/master/release.sh -[release-doc]: ../release +[dev-testing]: /docs/contribution-guidelines/testing +[dev-docs]: /docs/contribution-guidelines/documentation +[dev-release]: /docs/contribution-guidelines/releasing +[travis]: https://docs.travis-ci.com/ +[travis.yml]: https://github.com/operator-framework/operator-sdk/blob/master/.travis.yml +[travis-setup]: https://docs.travis-ci.com/user/tutorial/#to-get-started-with-travis-ci-using-github diff --git a/website/content/en/docs/contribution-guidelines/documentation.md b/website/content/en/docs/contribution-guidelines/documentation.md new file mode 100644 index 0000000000..a125cbbbf3 --- /dev/null +++ b/website/content/en/docs/contribution-guidelines/documentation.md @@ -0,0 +1,44 @@ +--- +title: Documentation +linkTitle: Documentation +weight: 20 +--- + +This document discusses how to visually inspect documentation changes as they would be applied +to the live website. All changes to documentation should be inspected locally before being pushed +to a PR. + +## Prerequisites + +The docs are built with [Hugo][hugo] which can be installed along with the +required extensions by following the [docsy install guide][docsy-install]. + +Note: Be sure to install hugo-extended. + +We use `git submodules` to install the docsy theme. From the +`operator-sdk` directory, update the submodules to install the theme. + +```sh +git submodule update --init --recursive +``` + +## Build and Serve + +You can build and serve your docs to `localhost:1313`. From the `website/` +directory run: + +```sh +hugo server +``` + +Any changes will be included in real time. + + +## Check Links + +`make test-links` will use containers to build html and check the links. +Please consider running this locally before creating a PR to save CI resources. + + +[hugo]:https://gohugo.io/ +[docsy-install]:https://www.docsy.dev/docs/getting-started/#prerequisites-and-installation diff --git a/website/content/en/docs/contribution-guidelines/local-changes.md b/website/content/en/docs/contribution-guidelines/local-changes.md deleted file mode 100644 index 85283ecae4..0000000000 --- a/website/content/en/docs/contribution-guidelines/local-changes.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Testing Changes Locally -linkTitle: Local Changes ---- - -## Testing Changes Locally - -If your changes are in the SDK commands then you just need to run `make install` to be able to use an SDK binary built from the source code and then test locally it. Also, see that you can run `operator-sdk version` to check what is the commit used to built it. - -However, If the change performed is NOT in the scaffold files or sdk commands then, is required to build an new image with the changes done to test it locally in a POC operator project. In this way, by using this dev image in an operator project locally we will be able to check the changes made for the Ansible/Helm based-operator. And then, for the GO based-operators, will be required ensure that you are import your version of code implementation to be used in the POC operator project were it will be checked. - -### For Ansible - -- Update the `ANSIBLE_BASE_IMAGE` var in the [Makefile][makefile] to generate an image for your repository (quay.io or docker.hub.io). See: - -Replace: - -``` -quay.io/operator-framework/ansible-operator -``` - -With (eg): - -``` -quay.io/my-repo-user/ansible-operator -``` - -- Build the image locally by running `make image-build-ansible` -- Push your new image. (E.g `docker push quay.io/my-repo-user/ansible-operator:dev`) - -**NOTE** Ensure that you configured the repo, `quay.io/my-repo-user/ansible-operator`, to be public. - -- Update the `Dockerfile` of your POC project to test your changes with the new image as follows. - -``` -FROM quay.io/my-repo-user/ansible-operator:dev - -COPY watches.yaml ${HOME}/watches.yaml -COPY roles/ ${HOME}/roles/ -``` - -### For Helm - - -- Update the `HELM_BASE_IMAGE` var in the [Makefile][makefile] to generate an image for your repository (quay.io or docker.hub.io). See: - -Replace: - -``` -quay.io/operator-framework/helm-operator -``` - -With (eg): - -``` -quay.io/my-repo-user/helm-operator -``` - -- Build the image locally by running `make image-build-helm` -- Push your new image. (E.g `docker push quay.io/my-repo-user/helm-operator:dev`) - -**NOTE** Ensure that you configured the repo, `quay.io/my-repo-user/helm-operator`, to be public. - -- Update the `Dockerfile` of your POC project to test your changes with the new image as follows. - -``` -FROM quay.io/my-repo-user/helm-operator:dev - -COPY watches.yaml ${HOME}/watches.yaml -COPY helm-charts/ ${HOME}/helm-charts/ -``` - -### For Go - -Following an example over how to test the changes made from a source code of a fork PR. - -- Update the `go.mod` file of the POC operator project with a replace for the fork. See: - -``` -require ( - ... - github.com/operator-framework/operator-sdk v0.0.0 - ... -) - -// # Add a replace to the fork and branch with the changes -replace github.com/operator-framework/operator-sdk => github.com//operator-sdk -``` - -[makefile]: https://github.com/operator-framework/operator-sdk/blob/master/Makefile diff --git a/website/content/en/docs/contribution-guidelines/local-docs.md b/website/content/en/docs/contribution-guidelines/local-docs.md deleted file mode 100644 index 97fd4d9083..0000000000 --- a/website/content/en/docs/contribution-guidelines/local-docs.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: Build and serve the docs locally -linkTitle: Local Docs ---- - -## Prerequisites - -Clone the repository: - -``` -$ git clone https://github.com/operator-framework/operator-sdk/ -``` - -The docs are built with [Hugo](https://gohugo.io/) which can be installed along with the -required extensions by following the [docsy install -guide](https://www.docsy.dev/docs/getting-started/#prerequisites-and-installation). - -Note: Be sure to install hugo-extended. - -We use `git submodules` to install the docsy theme. From the -`operator-sdk` directory, update the submodules to install the theme. - -``` -$ git submodule update --init --recursive -``` - -## Build and Serve - -You can build and serve your docs to localhost:1313. From the `website` -directory run: - -``` -hugo server -``` - -Any changes will be included in real time. - - -## Check Links - -`make test-links` will use containers to build html and check the links. -Please consider running this locally before creating a PR to save CI resources. diff --git a/website/content/en/docs/contribution-guidelines/release.md b/website/content/en/docs/contribution-guidelines/releasing.md similarity index 99% rename from website/content/en/docs/contribution-guidelines/release.md rename to website/content/en/docs/contribution-guidelines/releasing.md index 386dcfece2..2f9c879310 100644 --- a/website/content/en/docs/contribution-guidelines/release.md +++ b/website/content/en/docs/contribution-guidelines/releasing.md @@ -1,5 +1,6 @@ --- title: Release Guide +linkTitle: Releasing weight: 30 --- diff --git a/website/content/en/docs/contribution-guidelines/reporting-issues.md b/website/content/en/docs/contribution-guidelines/reporting-issues.md index 58461f4fcc..7ea456bd6e 100644 --- a/website/content/en/docs/contribution-guidelines/reporting-issues.md +++ b/website/content/en/docs/contribution-guidelines/reporting-issues.md @@ -1,6 +1,7 @@ --- title: Reporting Issues -weight: 30 +linkTitle: Reporting Issues +weight: 40 --- If any part of the operator-sdk project has bugs or documentation mistakes, please let us know by [opening an issue][operator-sdk-issue]. We treat bugs and mistakes very seriously and believe no issue is too small. Before creating a bug report, please check that an issue reporting the same problem does not already exist. diff --git a/website/content/en/docs/contribution-guidelines/testing.md b/website/content/en/docs/contribution-guidelines/testing.md new file mode 100644 index 0000000000..742785ba6c --- /dev/null +++ b/website/content/en/docs/contribution-guidelines/testing.md @@ -0,0 +1,47 @@ +--- +title: Testing +linkTitle: Testing +weight: 10 +--- + +On all PRs, a suite of static and cluster tests is run against your changes in a CI environment. +These tests can also be run locally, which is discussed [below](#local-test-environment). + +Static tests consist of [unit][unit-tests], formatting, and doc link tests. + +Cluster tests consist of several test types: +- End-to-end (e2e): simulate the "happy path" usage of the `operator-sdk` binary and resulting operator project. +- Integration: test components of the `operator-sdk` binary and features of scaffolded projects that are +bound to external projects, such as [OLM][olm]. +- Subcommand: ensure individual subcommands function as intended with a variety of input options. + +## Local Test Environment + +If running tests locally, access to a Kubernetes cluster of server version v1.11.3 or higher is required. +These tests require `KUBECONFIG` be set or kubeconfig file be present in a default location like `$HOME/.kube/config`. + +You will also need to set up an `envtest` environment for cluster tests. Follow [this doc][envtest-setup] +for setup instructions. + +### Local clusters + +Two options for testing with a local cluster are [minikube][minikube] and [kind][kind]. +Ensure `KUBECONFIG` is set correctly for the chosen cluster type. + +## Running Tests + +On any PR, the entire test suite is run against your changes in a CI environment. +Therefore it is advantageous to run all tests before pushing changes to the remote repo: + +```sh +make test-sanity test-links test-unit test-subcommand test-integration test-e2e +``` + +All the tests are run through the [`Makefile`][makefile]. Run `make help` for a full list of available tests. + +[unit-tests]: https://onsi.github.io/gomega/ +[olm]: https://olm.operatorframework.io/ +[minikube]: https://kubernetes.io/docs/setup/learning-environment/minikube/ +[kind]: https://kind.sigs.k8s.io/ +[envtest-setup]: /docs/building-operators/golang/references/envtest-setup +[makefile]: https://github.com/operator-framework/operator-sdk/blob/master/Makefile diff --git a/website/content/en/docs/contribution-guidelines/testing/_index.md b/website/content/en/docs/contribution-guidelines/testing/_index.md deleted file mode 100644 index 6f120113ab..0000000000 --- a/website/content/en/docs/contribution-guidelines/testing/_index.md +++ /dev/null @@ -1,4 +0,0 @@ ---- -title: Testing -weight: 30 ---- diff --git a/website/content/en/docs/contribution-guidelines/testing/running-the-tests.md b/website/content/en/docs/contribution-guidelines/testing/running-the-tests.md deleted file mode 100644 index c57a120112..0000000000 --- a/website/content/en/docs/contribution-guidelines/testing/running-the-tests.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Running Tests -weight: 30 ---- - -The operator-sdk is automatically tested with a variety of tests anytime -a pull request is made. The E2E tests ensure that the operator-sdk acts as intended by -simulating how a typical user might use the SDK. The automated tests test each PR and run in -Travis CI, and Travis CI has a couple of features to simplify the E2E tests that we run. For -a more in depth description of the tests that Travis runs, please read the [Travis Build][travis] doc. -This doc will talk about how to run the tests locally as well. - -## Running the Tests Locally - -To run the tests locally, the tests either need access to a remote Kubernetes cluster or a -local Kubernetes instance running on the machine. - -### Remote Kubernetes Instance - -To run the tests on a remote cluster, the tests need access to a remote Kubernetes cluster -running Kubernetes 1.11.3 or higher as well as a docker image repo to push the operator image to, -such as [`quay.io`][quay]. Your kubeconfig must be located at `$HOME/.kube/config` and certain -tests will not run on remote clusters. See [Running the Tests](#running-the-tests) for more details. - -### Local minikube or kind - -Two other options for testing are [minikube][minikube] and [kind][kind]. - -#### minikube - -To start the minikube cluster, download and install the proper [binary][minikube-binary] for your system and run these commands: - -```sh -# K8S_VERSION determines which Kubernetes cluster version minikube will provision. -$ minikube start --kubernetes-version ${K8S_VERSION} -$ eval $(minikube docker-env) -``` - -#### kind - -To start the kind cluster, either run [`hack/ci/setup-k8s.sh`][k8s-script] then: - -```sh -$ export KUBECONFIG="$(kind get kubeconfig-path --name="kind")" -``` - -Or you can download and install the proper [binary][kind-binary] for your system and run these commands: - -```sh -# K8S_VERSION determines which Kubernetes image version kind will use to provision the cluster. -$ kind create cluster --image="docker.io/kindest/node:${K8S_VERSION}" -$ export KUBECONFIG="$(kind get kubeconfig-path --name="kind")" -``` - -## Running the tests - -All the tests are run through the [`Makefile`][makefile]. This is a brief description of all makefile test instructions: - -- `test` - Runs the unit tests (`test-unit`). -- `test-ci` - Runs sanity and unit tests, installs the SDK binary, and runs the SDK subcommand and all E2E tests. -- `test-sanity` - Runs sanity checks. -- `test-unit` - Runs unit tests. -- `test-subcommand` - Runs subcommand tests. -- `test-e2e` - Runs all E2E tests (`test-e2e-go`, `test-e2e-ansible`, `test-e2e-ansible-molecule`, and `test-e2e-helm`). -- `test-e2e-go` - Runs the go E2E test. -- `test-e2e-ansible` - Runs the ansible E2E test. -- `test-e2e-ansible-molecule` - Runs the ansible molecule E2E test. -- `test-e2e-helm` - Runs the helm E2E test. - -For more info on what these tests actually do, please see the [Travis Build][travis] doc. - -Some of the tests will run using the kube config in `$HOME/.kube/config` (others may check the `KUBECONFIG` env var first) -and the operator images will be built and stored in you local docker registry. - -### Go E2E test flags - -The `make test-e2e-go` command accepts an `ARGS` variable containing flags that will be passed to `go test`: - -- `-image-name` string - Sets the operator test image tag to be built and used in testing. Defaults to "quay.io/example/memcached-operator:v0.0.1" -- `-local-repo` string - Sets the path to the local SDK repo being tested. Defaults to the path of the SDK repo containing e2e tests. This is useful for testing customized e2e code. - -An example of using `ARGS` is in the note below. - -**NOTE**: Some of these tests, specifically the ansible (`test-e2e-ansible`), helm (`test-e2e-helm`), and Go (`test-e2e-go`) tests, -only work when the cluster shares the local docker registry, as is the case with `oc cluster up` and `minikube` after running `eval $(minikube docker-env)`. - -```sh -$ kind load docker-image -``` - -For each image built or used by the kind cluster. - -All other tests will run correctly on a remote cluster if `$HOME/.kube/config` points to the remote cluster and your -`KUBECONFIG` env var is either empty or is set to the path of a kubeconfig for the remote cluster. - -## Cleanup of the Go E2E Tests - -The E2E tests create a new project using the operator-sdk to run in the provided -cluster. The tests are designed to cleanup everything that gets created, but some errors -during the go tests can cause these cleanups to fail (the ansible and helm E2E tests should -always clean up correctly). For example, if a segfault occurs or a user kills the -testing process, the cleanup functions for the go tests will not run. To manually clean up a test: - -1. Delete the CRD (`kubectl delete crd memcacheds.cache.example.com`). -2. Delete the namespaces that the tests run in, which also deletes any resources created within the namespaces. The namespaces start with `memcached-memcached-group` or `main` and are appended with a unix timestamp (seconds since Jan 1 1970). The kubectl command can be used to delete namespaces: `kubectl delete namespace $NAMESPACE`. - -[travis]: ../travis-build -[quay]: https://quay.io -[minikube]: https://github.com/kubernetes/minikube -[minikube-binary]: https://github.com/kubernetes/minikube/releases -[kind]: https://github.com/kubernetes-sigs/kind -[kind-binary]: https://github.com/kubernetes-sigs/kind/releases -[k8s-script]: https://github.com/operator-framework/operator-sdk/blob/master/hack/ci/setup-k8s.sh -[makefile]: https://github.com/operator-framework/operator-sdk/blob/master/Makefile diff --git a/website/content/en/docs/contribution-guidelines/testing/travis-build.md b/website/content/en/docs/contribution-guidelines/testing/travis-build.md deleted file mode 100644 index a41da836a2..0000000000 --- a/website/content/en/docs/contribution-guidelines/testing/travis-build.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Travis CI -weight: 30 ---- - -Travis is set to run one every push to a branch or PR. -The results of the builds can be found [here][branches] for branches and [here][pr-builds] for PRs. - -## Test Workflow - -In Travis CI, 4 jobs are run to test the sdk: - -- [Go](#go-tests) -- [Ansible](#ansible-tests) -- [Helm](#helm-tests) - -### Before Install for Go, Ansible, and Helm - -For the Go, Ansible, and Helm tests, the `before_install` and `install` stages are the same: - -1. Check if non documentation files have been updated. - - If only documentation has been updated, skip these tests. -2. Run `make tidy` to ensure `go.mod` and `go.sum` are up-to-date. -3. Build and install the sdk using `make install`. -4. Install ansible using `sudo pip install ansible`. -5. Run the [`hack/ci/setup-k8s.sh`][k8s-script] script, which spins up a [kind][kind] Kubernetes cluster of a particular version by configuring docker, and downloads the `kubectl` of the same version. - -The Go, Ansible, and Helm tests then differ in what tests they run. - -### Go Tests - -1. Run some basic [sanity checks][sanity]. - 1. Run `go vet`. - 2. Check that all source files have a license. - 3. Check that all error messages start with a lower case alphabetical character and do not end with punctuation, and log messages start with an upper case alphabetical character. - 4. Make sure the repo is in a clean state (this is particularly useful for making sure `go.mod` and `go.sum` are up-to-date after running `make tidy`). -2. Run unit tests. - 1. Run `make test-unit`. -3. Run [go e2e tests][go-e2e]. - 1. Run `make test-e2e-go`. - -### Ansible tests - -1. Run [ansible molecule tests][ansible-molecule]. (`make test-e2e-ansible-molecule`) - 1. Create and configure a new ansible type memcached-operator. - 2. Create cluster resources. - 4. Change directory to [`test/ansible`][ansible-test] and run `molecule test -s local` - -**NOTE**: All created resources, including the namespace, are deleted using a bash trap when the test finishes - -### Helm Tests - -1. Run [helm e2e tests][helm-e2e]. - 1. Build base helm operator image. - 1. Create and configure a new helm type nginx-operator. - 1. Create cluster resources. - 1. Wait for operator to be ready. - 1. Create nginx CR and wait for it to be ready. - 1. Scale up the dependent deployment and verify the operator reconciles it back down. - 1. Scale up the CR and verify the dependent deployment scales up accordingly. - 1. Delete nginx CR and verify that finalizer (which writes a message in the operator logs) ran. - -**NOTE**: All created resources, including the namespace, are deleted using a bash trap when the test finishes - -[branches]: https://travis-ci.org/operator-framework/operator-sdk/branches -[pr-builds]: https://travis-ci.org/operator-framework/operator-sdk/pull_requests -[k8s-script]: https://github.com/operator-framework/operator-sdk/blob/master/hack/ci/setup-k8s.sh -[kind]: https://kind.sigs.k8s.io/ -[sanity]: https://github.com/operator-framework/operator-sdk/blob/master/hack/tests/sanity-check.sh -[go-e2e]: https://github.com/operator-framework/operator-sdk/blob/master/hack/tests/e2e-go.sh -[ansible-molecule]: https://github.com/operator-framework/operator-sdk/blob/master/hack/tests/e2e-ansible-molecule.sh -[ansible-test]: https://github.com/operator-framework/operator-sdk/tree/master/test/ansible -[helm-e2e]: https://github.com/operator-framework/operator-sdk/blob/master/hack/tests/e2e-helm.sh