Travis CI

Travis is set to run one every push to a branch or PR. The results of the builds can be found here for branches and here for PRs.

Test Workflow

In Travis CI, 4 jobs are run to test the sdk:

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 script, which spins up a 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.
    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.
    1. Run make test-e2e-go.

Ansible tests

  1. Run ansible molecule tests. (make test-e2e-ansible-molecule)
    1. Create and configure a new ansible type memcached-operator.
    2. Create cluster resources.
    3. Change directory to test/ansible 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.
    1. Build base helm operator image.
    2. Create and configure a new helm type nginx-operator.
    3. Create cluster resources.
    4. Wait for operator to be ready.
    5. Create nginx CR and wait for it to be ready.
    6. Scale up the dependent deployment and verify the operator reconciles it back down.
    7. Scale up the CR and verify the dependent deployment scales up accordingly.
    8. 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

Last modified September 16, 2020: [1.0.x] Fix broken links (#3893) (cfabe8d6)