* Use Quartz-based hosted service to clear old play data
We need to stop possible bloat of databases should users of a seeded data fail to appropriately clean up after themselves.
Using the hosted services present in other projects, this adds an alive job and play data delete job to the SeederApi
* Trigger play data delete frequently enough for dev servers
Development servers are unlikely to be running at midnight UTC, so we need to delete more frequently to ensure data is cleaned up. The Job still deletes things older than a day, it just checks much more frequently, now.
* Fixup sonarqube
* Fixup parallel test issues with jobs hosted services
* Remove alive job and unneeded fixme
* Revert "Remove alive job and unneeded fixme"
This reverts commit 0c10e4a675.
* Simplify alive job
Used the wrong job as a template, the api alive job is much more like what we want.
* Update readme to callout ephemeral data
* Seed passkeys
Generates passkey data from minimal inputs or relying party and username
* Allow totp specifying to user login cipher scene
* Fixup test
* Use default values in seed DTOs where possible
* Limit classes to one per file
* Scenes should return resulting data in the result object
The result is for data that cannot be known by the client requesting the scene and the mangle map used for mangling input values to enable parallelizing tests
* Fix filenames
* SingleUserScene now has a return value of various created User data
* 1/100 too frequent for false test failures
We want to reduce the amount of business critical test data in the company. One way of doing that is to generate test data on demand prior to client side testing.
Clients will request a scene to be set up with a JSON body set of options, specific to a given scene. Successful seed requests will be responded to with a mangleMap which maps magic strings present in the request to the mangled, non-colliding versions inserted into the database. This way, the server is solely responsible for understanding uniqueness requirements in the database. scenes also are able to return custom data, depending on the scene. For example, user creation would benefit from a return value of the userId for further test setup on the client side.
Clients will indicate they are running tests by including a unique header, x-play-id which specifies a unique testing context. The server uses this PlayId as the seed for any mangling that occurs. This allows the client to decide it will reuse a given PlayId if the test context builds on top of previously executed tests. When a given context is no longer needed, the API user will delete all test data associated with the PlayId by calling a delete endpoint.
---------
Co-authored-by: Matt Gibson <mgibson@bitwarden.com>
