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`.
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.
* [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>
Josh Brand
Michael Li
Johan Brandhorst-Satzkorn
Ryan Cragun
Jaymala
