* Reorganize the db migration .sql scripts into individual schema version directories and generate the sql httpfs fakeFile accordingly.
* Created a /dev schema version directory to hold db schema updates that have not been finalized.
* Add an 'allow-development-migrations' flag to allow `boundary database init` to be executed even when there are schema updates in /dev.
* Revert "Refactor domain error to use errorId (#790)"
This reverts commit d30dd0ff64.
* Revert "Create common errorID generation (#788)"
This reverts commit b8a5b9adf1.
* Update ui build to use 'admin' folder instead of 'core'
Post release of v0.1.2, ui/core folder has been renamed to ui/admin.
Update ui build scripts to be aware of the path change.
* Update packagespec to reflect "admin" ui folder change
* feat: make auth token time to live and staleness configurable
* docs: add configuration docs for auth token TTL and staleness
Co-authored-by: Jeff Mitchell <jeffrey.mitchell@gmail.com>
* Update deps
This also updates for the new (and required) paradigm for registering
service implementations as spelled out in
https://github.com/grpc/grpc-go/issues/3385
* Roll back dockertest
* Update ui version to latest for next release
* Bump up ui version to pick up org label fix
* chore: update changelog with ui scope awareness
Co-authored-by: Susmitha Girumala <susmitha@hashicorp.com>
We have behavior that causes "0.0.0.0" to only listen on IPv4, however,
it also assumed there was a port suffixed. This changes it so that it
also works with a port-less address.
* tests: ensure default user can connect to default target and ensure created target has intended host sets
* docs: update readme for CLI tests with how to run against arbitrary clusters
* feat: override auth variables in CLI tests
This was always an RPC-only distinction and from that perspective it
makes sense; however it causes the generated docs to treat it as an
entirely separate service even though it's under the same collection
path as auth methods and this is confusing.
It's possible there are acceptable use cases for still matching account
ID if the account no longer maps to a user, but it's equally possible
that this can cause confusion. Removing it seems safer.