* 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
* Add Enos CI bootstrapping scenarios
* Add GitHub Actions workflow for CI bootstrapping
* Add service quotas limit increase request to Enos CI bootstrapping
* Onboard boundary to use new .release/VERSION file and reproducible actions-go-build
* Added automatic patch version bumps to end of release pipeline
* Added back VersionMetadata to internal directory
* Moved VERSION file to version/
* Update to current version
* Using prepare workflow for pre-stable channel workflow
* Test prepare workflow
* PR feedback: allow builds to run builds locally without setting BIN_PATH
* PR feedback: revert Enos changes
* PR Feedback
* Remove current branch from ci pipeline
* Run make fmt
Rearranges the directory structure to align better with the enos scenarios. Tests will now be added in the `tests` directory, with a folder in the directory corresponding to an enos scenario.
This adds a github actions workflow to run the new e2e test suite
Co-authored-by: Michael Anthony <manthony@hashicorp.com>
Co-authored-by: Josh Brand <jbrand@hashicorp.com>
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.
Disable the fail-fast feature for the matrix strategy. This prevents a
single failure to cascade to all jobs in the matrix. This prevents cases
where other jobs fail before they're able to clean up resources.
Signed-off-by: Ryan Cragun <me@ryan.ec>
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.
Josh Brand
Michael Li
Ashlee M Boyer
Irena Rindos
Jeff Mitchell
Mike Baum
Danielle
Mike Baum
emily neil
Michael Anthony
Timothy Messier
Ryan Cragun
Jaymala
Michele Degges
Damian Debkowski
Sam Salisbury
Todd
Carlos Alcaide Corvo
Sarah Thompson
claire labry
modrake
