Files
threshold/testing/internal/e2e
hashicorp-copywrite[bot]andJohan Brandhorst-Satzkorn 29da0bcb92 [COMPLIANCE] License changes (#3567)
* Adding explicit MPL license for sub-package.

This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.

* Adding explicit MPL license for sub-package

This directory and its subdirectories (packages) contain files licensed with the MPLv2 `LICENSE` file in this directory and are intentionally licensed separately from the BSL `LICENSE` file at the root of this repository.

* Updating the license from MPL to Business Source License

Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at www.hashicorp.com/licensing-faq, and details of the license at www.hashicorp.com/bsl.

* Update copyright file headers to BUS-1.1

* Rerun make gen

This will pick up the last of the license changes

* Revert "Rerun make gen"

This reverts commit dbe0968bffd92745d8663c6940debae098395a6b.

* Remove copywrite from generation script

The current version of copywrite is not sophisticated enough
to only apply the copywrite changes to certain subdirectories,
so to avoid accidentally relicensing our api and sdk modules,
we will stop running the copywrite script until such time
that it can do the right thing.

* License protobuf API as MPL

The protobuf API files are used to generate the SDK,
since we want the SDK to be MPL, the protobuf files
must also be MPL. This extends to all protobuf files
whose sources end up in the SDK directory, including:

- internal/proto/controller/api
- internal/proto/controller/custom_options
- internal/proto/plugin

It also includes the generated service directory in
internal/gen/controller/api/services, since they are
generated from the protobuf sources used for the SDK.

* Change website license file name

This makes the naming scheme consistent with the rest
of the repository.

* Add note on licensing to README

* Set copywrite license to BUSL

* Revert "Add note on licensing to README"

This reverts commit 4d865a91a7a4f11605f0dc4609355d7e3c3cfffe.

---------

Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
2023-08-11 10:31:53 -07:00
..

boundary-e2e-tests

This test suite tests Boundary in an end-to-end setting, utilizing both the Boundary CLI and the Boundary Go API to exercise Boundary through various user workflows. It was designed to be run in a variety of environments as long as the appropriate environment variables are set. The test suite itself uses the standard go test library.

One method for setting up an environment is utilizing Enos to create the desired infrastructure.

Getting Started

Enos

Setup Enos as described here

Then, use the following commands to run tests

cd enos
enos scenario list

# `Run` executes the tests and destroys the associated infrastructure in one command
enos scenario run e2e_{scenario} builder:local

# `Launch` executes the tests, but leaves the infrastructure online for debugging purposes
enos scenario launch e2e_{scenario} builder:local
enos scenario output  # displays any defined enos output
enos scenario destroy  # destroys infra

Enos scenarios set up the infrastructure, set the appropriate environment variables, and run the specified tests in its scenario file.

Note: To run the e2e_host_aws scenario, you will need access to the boundary team's test AWS account.

Local

Set the appropriate environment variables...

export E2E_TESTS=true  # This is needed for any e2e test. Otherwise, the test is skipped

# For e2e/tests/base
export BOUNDARY_ADDR=  # e.g. http://127.0.0.1:9200
export E2E_PASSWORD_AUTH_METHOD_ID=  # e.g. ampw_1234567890
export E2E_PASSWORD_ADMIN_LOGIN_NAME=  # e.g. "admin"
export E2E_PASSWORD_ADMIN_PASSWORD=  # e.g. "password"

export E2E_TARGET_IP=  # e.g. 192.168.0.1
export E2E_SSH_KEY_PATH=  # e.g. /Users/username/key.pem
export E2E_SSH_USER=  # e.g. ubuntu

# For e2e/tests/base_with_vault
export BOUNDARY_ADDR=  # e.g. http://127.0.0.1:9200
export E2E_PASSWORD_AUTH_METHOD_ID=  # e.g. ampw_1234567890
export E2E_PASSWORD_ADMIN_LOGIN_NAME=  # e.g. "admin"
export E2E_PASSWORD_ADMIN_PASSWORD=  # e.g. "password"

export VAULT_ADDR=  # e.g. http://127.0.0.1:8200
export VAULT_TOKEN=
export E2E_TARGET_IP=  # e.g. 192.168.0.1
export E2E_SSH_KEY_PATH=  # e.g. /Users/username/key.pem
export E2E_SSH_USER=  # e.g. ubuntu

# For e2e/tests/aws
export BOUNDARY_ADDR=  # e.g. http://127.0.0.1:9200
export E2E_PASSWORD_AUTH_METHOD_ID=  # e.g. ampw_1234567890
export E2E_PASSWORD_ADMIN_LOGIN_NAME=  # e.g. "admin"
export E2E_PASSWORD_ADMIN_PASSWORD=  # e.g. "password"

export E2E_AWS_ACCESS_KEY_ID=
export E2E_AWS_SECRET_ACCESS_KEY=
export E2E_AWS_HOST_SET_FILTER=  # e.g. "tag:testtag=true"
export E2E_AWS_HOST_SET_IPS=  # e.g. "[\"1.2.3.4\", \"2.3.4.5\"]"
export E2E_AWS_HOST_SET_FILTER2=  # e.g. "tag:testtagtwo=test"
export E2E_AWS_HOST_SET_IPS2=  # e.g. "[\"1.2.3.4\"]
export E2E_SSH_KEY_PATH=  # e.g. /Users/username/key.pem
export E2E_SSH_USER=  # e.g. ubuntu

# For e2e/tests/database
export E2E_AWS_ACCESS_KEY_ID=
export E2E_AWS_SECRET_ACCESS_KEY=
export E2E_AWS_HOST_SET_FILTER=  # e.g. "tag:testtag=true"
export VAULT_ADDR=  # e.g. http://127.0.0.1:8200
export VAULT_TOKEN=

Then, run...

go test github.com/hashicorp/boundary/testing/internal/e2e/tests/base
go test ./target/ // run target tests if running from this directory
go test github.com/hashicorp/boundary/testing/internal/e2e/tests/base -v // verbose
go test github.com/hashicorp/boundary/testing/internal/e2e/tests/base -v -run '^TestCreateTargetApi$' // run a specific test

Adding Tests

Tests live in the tests/ directory. Additional tests can be added to an existing go package or a new one can be created. If a new package is created, a new enos scenario would also need to be created.

Enos is comprised of scenarios, where a scenario is the environment you want the tests to operate in. In one scenario, there may be a boundary cluster and a target. Another scenario might involve a boundary cluster and a vault instance. Scenarios can be found in boundary/enos

To run these tests in CI, the enos-run.yml github action workflow must be updated to include the new scenario (see the matrix).

Development

To assist with iterating on tests on enos launched infrastructure, you can perform the following...

Launch an enos scenario and print out the environment variables

cd enos
enos scenario launch e2e_{scenario} builder:local
bash scripts/test_e2e_env.sh

Take the printed environment variable information and export them into another terminal session

export BOUNDARY_ADDR=
export E2E_PASSWORD_AUTH_METHOD_ID=
...

Run your tests

go test -v {go package}