Service
Not service specific. Flock-wide request
API Action / Feature
Nuke every stored data to start from a clean slate.
AWS Documentation
Not applicable
Why is this needed?
As we write automation tests, they often have fail runs. Maybe the test was supposed to verify production code will create an SQS queue and at the end of the test the queue will be deleted to clean up state. But if for some reason the queue is created but the test fails before it finishes cleaning up the queue, subsequent run end up failing because queue already exists. We end up having to do more testing orchestration and/or kill the container and start over.
In the world of transactional database it's very common to use DB transactions where the test framework rolls back the DB when the test finishes, regardless of whether the test succeeded or not. This works because the testing framework is configured for a generic operation of starting transaction and rolling back and doesn't require test-specific instructions. For AWS resources
I don't want my test framework to have to go through all resources verifying if something exists to then delete it. It would be much better if floci could provide an API that we call to nuke / truncate / delete everything. Regardless if the test pass or fail I could call it and know that every test will start from a clean slate.
Are you willing to contribute a PR?
I might need some guidance with 1 or 2 paragraph recommendation on where to start, but if there's a positive evaluation of the idea I'm willing to try it
Service
Not service specific. Flock-wide request
API Action / Feature
Nuke every stored data to start from a clean slate.
AWS Documentation
Not applicable
Why is this needed?
As we write automation tests, they often have fail runs. Maybe the test was supposed to verify production code will create an SQS queue and at the end of the test the queue will be deleted to clean up state. But if for some reason the queue is created but the test fails before it finishes cleaning up the queue, subsequent run end up failing because queue already exists. We end up having to do more testing orchestration and/or kill the container and start over.
In the world of transactional database it's very common to use DB transactions where the test framework rolls back the DB when the test finishes, regardless of whether the test succeeded or not. This works because the testing framework is configured for a generic operation of starting transaction and rolling back and doesn't require test-specific instructions. For AWS resources
I don't want my test framework to have to go through all resources verifying if something exists to then delete it. It would be much better if floci could provide an API that we call to nuke / truncate / delete everything. Regardless if the test pass or fail I could call it and know that every test will start from a clean slate.
Are you willing to contribute a PR?
I might need some guidance with 1 or 2 paragraph recommendation on where to start, but if there's a positive evaluation of the idea I'm willing to try it