Several of these tests are being skipped in the enos
run. This seems to be due to differences in the setup that is performed.
When these tests were run manually, `boundary dev` was used which
performs some setup of resources automatically. However since enos uses
a non-dev controller, a similar setup is performed via the enos modules.
Until the discrepancies between the setup can be investigated, this adds
a separate CI job to run the tests against `boundary dev`. These tests
are all passing, without any being skipped. This test suite can still be
useful even if the enos version is fixed, since this test suite will run
much faster, and therefore identify failures sooner.
Enos jobs are still a bit unstable, we should use them as
advisory for now. When they have gained more stability,
we can let them fail pipelines again.
* [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>
These github actions run on Ubuntu based machine. Ubuntu by default
links `/bin/sh` to dash. So by invoking the plugin.sh script as `/bin/sh
./plugins.sh` the script would run under `dash` despite the shebang
line. A recent change that unified some of the build process, introduced
additional bashisms into this script which is caused the build to fail.
This updated the build system to just run the script directly, which
will honor the shebang line. This seems like the best approach since the
ubuntu machine has bash and the shebang line points to bash, so it is
natural for developers to assume bashisms will work.
See:
f370abc1dahttps://github.com/actions/virtual-environments/blob/ubuntu20/20220410.2/images/linux/Ubuntu2004-Readme.mdhttps://wiki.ubuntu.com/DashAsBinSh
Some OS build steps were not compiling the plugins before compiling the
boundary binary. This resulted in binaries that did not have plugins
included, and would result in an error when starting a boundary server.
Timothy Messier
Johan Brandhorst-Satzkorn
Michele Degges
Ryan Cragun
Damian Debkowski
Sam Salisbury
Carlos Alcaide Corvo
Jeff Mitchell
Sarah Thompson
claire labry
modrake
