This fixes occurences of a loop variable being captured in parallel
tests. With the previous code, only the last test case is actually
exercised. To work around this problem, we create a local copy of the
range variable before the parallel test, as suggested in the
documentation for the `testing` package:
https://pkg.go.dev/testing#hdr-Subtests_and_Sub_benchmarks
Issues were found automatically using the `loopvarcapture` linter.
This adds the ability to define hooks that will run prior to a schema
migration. The hooks should only be used when a migration would fail due
to data being in an invalid state, likely due to a bug in the previous
schema definition. For example if a column was missing a constraint, and
a new migration is attempting to add the constraint, there might already
be values that violate the new constraint. In such cases, we would want
the user to make a decision to address the data, and need to provide
them with details about what data is problematic in case they want to
manually address the problem. To help the user, if there is a sane way
to address the data, we should provide an option to automatically
"repair" the data, allowing the migration to continue. However, this
still should be an explicit opt-in from the user, and we need to clearly
describe what the repair option would do to the user so they understand
the consequences of opting in.
To accomplish this each migration can be provided a hook that contains a
CheckFunc, RepairFunc, and RepairDescription. These functions must
operate at the point-in-time of the migration immediately preceding the
current migration, as as such they should not use and domain packages or
repositories, instead they should use direct sql with the sql library.
The description is used to explain what the RepairFunc will do.
Hooks should be defined in `internal/db/schema/migrations/oss/oss.go`
and registered with the schema edition.
See the example in `internal/db/schema/manager_example_test.go` for more
details.
This allows a check function to be set to determine whether it is
allowed to be set. This also ensures that if null is allowed it is
either the only value or not set.
* Add mechanism for plugin to normalize attributes
This introduces a new normalization call to the plugin RPC service. If
implemented, the plugin will be given the attributes prior to saving
them in a create/update call, and can perform any normalization needed,
e.g. ensuring that a parameter passed in is represented in a canonical
way. As an example, the CLI allows a user of the AWS plugin to pass in a
string, but canonically it is a string slice, and should be returned
that way as well. Not by chance, this is the exact behavior of the
testing implementation of this function.
This does not update any individual plugin, but rather sets the
controller-side logic up for plugins to support this functionality.
* chore(deps): Update grpc-gateway dependency
This fixes an issue which would allow an attacker to trigger a
(recovered) panic in the gateway handler.
* fix(server): Use cmp.Diff instead of assert.Equal
Testify is not great at handling protobuf types, and
was for some reason returning a diff here when in
reality there is none. Switch to go-cmp for the
comparison to remove the error.
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>
Johan Brandhorst-Satzkorn
Renato Costa
Irena Rindos
Jim
Louis Ruch
Damian Debkowski
Timothy Messier
Michael Gaffney
Jeff Mitchell
Zhihe Li
Randall Morey
Michele Degges
Damian Debkowski
Todd