For a flag type used for attributes/secrets, values have always been
able to be used with env:// or file:// format, but the error check to
see whether the value was successfully parsed was doing a simple string
equality rather than `errors.Is`. As a result a value containing a colon
would trip up this check and cause an error, rather than allowing it to
be used as a bare value.
* chore: update go-dbw dependencies
This update included an update of the upstream gorm dependency.
In the latest update, gorm appears to have become more sensitive when
a slice is passed into operations. The ptr to slice must now
be a ptr to slice of ptrs. This change required an update to how
boundary handles slices of PrincipalRole, which now must return a ptr
to PrincipalRole. There were also some tests that needed to be
updated because of this change.
* fixup! chore: update go-dbw dependencies
The intention of the code was to have one-hop-away workers list KMS
workers to get initial upstreams, and have other workers continue using
what was in their config file. However, nothing stops people from having
initial_upstreams but _also_ adding a cluster ID in their config file,
in which case we'd always run this check and replace the config-set
initial upstreams. So, ensure the config-set initial upstreams is also
len zero.
* Revert "Remove `-token` flag (#2303)"
This reverts commit 65cff995d7.
* Change behavior of -token
* Add use of MustParsePath
* Update changelog
* Use errors.Is
* Add parsepath logic to password in various places:
* Account password create/set/change
* Authenticate
Also fixes a bug where confirmation on a change-password call would run
for the current password instead of the new one.
* Clean up some dev config kms code
Although it didn't matter in the combined state, the KMS for auth
storage was not actually being set properly if only a worker was being
instantiated.
* [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>
Louis Ruch
Zhihe Li
Jeff Mitchell
Randall Morey
Michael Gaffney
Jim
claire labry
Michele Degges
Ryan Cragun
Damian Debkowski