There was an update to the build scripts to detect what edition of boundary is being built so that it knows which version of the UI to grab. However, this affected instances when building boundary on an architecture that is not the same as the host (in this case, we're building a linux/amd64 version on a mac). When the scripts try to use the built CLI to get the edition, it threw an `exec format error`.
* refact(e2e): Explicitly define port used for targets
To maintain consistency for how we define ports, this change explicitly defines the port used in the enos
scenario as opposed to relying on a "default" value. This change is in support of work that attempts to
spin up test infrastructure using docker. The openssh-server image uses Port 2222, which needs to be
passed to the test suite.
* refact(e2e): Add optional "Internal" Vault Address parameter
This change enables scenarios that need two different Vault addresses, one used by the Vault CLI and
one by the Boundary server instance. In the case when using a Docker container, the Boundary server
needs the Vault address "internal" to the Docker network, whereas the Vault CLI running outside of the
network needs a different address.
* fix(enos): Make sure enos reports test as failure
After updating this command to save off the output from running `go test`, enos would not report when tests failed. This was due to the extra pipe hiding the exit status of the prior commands. Adding this option should return the status of the last command to exit with a non-zero status.
* doc(e2e): Fix comments
* refact(e2e): Update AuthenticateCli to accept auth method id
* refact(e2e/migration): Use docker to set up vault instead of enos
* refact(e2e/migration): Adjust where environment variables are set
This makes the `make` build target that is used for local builder
variant configurable. This will allow us to utilize the local builder
variant in downstreams that might use different targets for their build.
* Make the local build target configurable
* Allow cross compiling `linux/amd64` on different platforms.
* test(e2e): Add database migration test
* chore(enos): Add enos scenario for migration test
* chore(enos): Update go test command to use count option
* doc(e2e): Update readme with migration test details
* Fix: Typo
* CR: Use different library
* CR: Add additional context in comment
* CR: Move some code from test into functions
* doc(e2e): Add instructions to more easily retrieve environment variables
* refact(e2e): Create some more methods to increase test readability
* refact(e2e): Move cleanup steps into each test
The migration test needed to create some resources, but doesn't care about cleaning up because the test would take care of spinning down the docker container that it's using. To maintain flexibility going forward, we'll establish that tests are responsible for cleaning up (rather than the methods they use)
* refact(e2e): Use new env var for skip check
Currently, the e2e tests use the E2E_PASSWORD_AUTH_METHOD_ID environment variable to determine if the test should be skipped. However, the new migration test does not require a pre-existing boundary cluster and would not have this environment variable. As a result, we needed an alternative way to check if an e2e test should be skipped when running tests in ci.
* refact(e2e): Create more common boundary methods
* fix(e2e): Set to string value
Co-authored-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
This variable defines the IP address of a target used in tests. We should pass in the address itself instead of a list of addresses that will get converted to a single address eventually anyways.
* test(cli): Remove skips in CI for cli tests
* fix(enos): Fix enos bats tests
The tests still sometimes suffer from timing issues,
but I was able to run a successful run (setup, run, destroy)
of the tests from my machine at least once.
There were 2 issues:
- Some tests in groups.bats were hardcoding the default user id
- The default grants for a user in a project were missing
the permission to connect to a target. We now add this
explicitly.
Co-authored-by: Timothy Messier <tim.messier@gmail.com>
* [QTI-275] Add infrastructure integration testing
On pull requests that originate from branches of the `hashicorp/boundary`
repo, we now conditionally dispatch infrastructure integration tests using
the Enos framework. The `integration` Enos scenario includes two `builder`
variants which allow developers or CI to deploy a Boundary cluster in AWS
using either a local `boundary` install bundle or that which is produced
in the `build` workflow for CRT. The `test` variants determine which type
of infrastructure integration test to run. At present those options are
`cli_ui` (Bats CLI tests) or `smoke` (creates target instances and a
target host catalog and verifies that `boundary` works).
In addition to the new workflow and quality scenarios, we simplified the
some `build` workflow steps and added Go module caching to speed up the
build pipeline.
See the [enos/README.md](https://github.com/hashicorp/boundary/blob/main/enos/README.md)
for a detailed explanation on how to configure and execute Enos scenarios
from your machine.
Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Rebecca Willett <rwillett@hashicorp.com>
Co-authored-by: Josh Branch <jbrand@hashicorp.com>
Michael Anthony
Josh Brand
Michael Li
Mike Baum
Ryan Cragun
Louis Ruch
Jeff Mitchell
Jaymala
