* 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
* User Cipher scene
For now only supports one login cipher
* Fixup batch delete, which fails due to db collisions
* Create cipher scenes for each cipher type
* Remove unnecessary mutex locking
* Include notes in ssh key ciphers
* Add reprompt to ssh keys
* Add deleted and archived options to login cipher seeder
* Remove ArchivedDate for now
* Update util/Seeder/Factories/SshKeyCipherSeeder.cs
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
* Allow setting favorite in seeder
* Propagate favorites to created cipher
* Propagate delete date to cipher creation
fix favorites, which have to be all caps for detection on the client side
* conditionally set cipher as favorite
* More review comments
---------
Co-authored-by: claude[bot] <209825114+claude[bot]@users.noreply.github.com>
* create new dockerfile for SeederApi
* troubleshoot cargo issues
* troubleshoot cargo issues
* Ensure Rustup run on build env for appropriate target
* Musl targets do not support cdylibs
* Ensure default triple set to target
* Set target triple rather than update default host
* Change build platforms per project
* Switch to debian since we can't use musl
* Debian build for seeder should work with arm targets
* Move app stage to distroless
* remove SeederApi from server publish section
* suppress unrelated warnings"
* ruling out builds as error source
* override platforms for SeederApi
* troubleshoot matrix
* add extra step for evaluating platforms
* fix syntax error
* exclude unrelated error
* exclude unrelated error
* exclude unrelated error
* exclude unrelated error
* exclude unrelated error
* temporarily reduce number of builds
* exclude unrelated error
* remove temporary block on other builds
* remove unused builds from dockerfile
* add nginx location for seeder, wrap it behind an if check defaulting to false. This was discuss with Matt G, as this will enable QA usage of it without repetitive intervention with config files and reloading the nginx service etc. Handlebars will continously overwrite the nginx conf file on update
* opted to remove conditional location to seederApi, instead include additional conf files in the same directory allowing for extensibility and not directly placing the non-prod seeder location in the config builder
---------
Co-authored-by: Matt Gibson <mgibson@bitwarden.com>
Co-authored-by: AJ Mabry <81774843+aj-bw@users.noreply.github.com>
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>
