Evaluate cleanup policies and methods of live environments
Context
Motivation
Goals
Plan
-
... -
... -
...
💡
Ideas from @ddavison
comment:
I'm coming up short on the original thread that I had with @treagitlab
, but I still envision a Redis server that contains something like the following:
[
{ "resource": "Project", "id": 11111, "env": "gitlab.com", created_at: 2023-01-22 },
{ "resource": "Issue", "project_id": 11111, "id": 54321, "env": "gitlab.com", created_at: 2023-01-22 },
{ "resource": "Project", "id": 22222, "env": "staging.gitlab.com", created_at: 2023-01-22 }
]
And a pipeline schedule that consumes this Redis data, with this pseudo-script.
data = Redis.read
data.each do |datum|
env = parse_env(datum.env) #=> https://gitlab.com/api/v4/
translation = APITranslator.translate(datum, env) #=> #<Translation resource_url="https://gitlab.com/api/v4/projects/11111/issues/54321" method="DELETE">
translation.delete! #=> HTTP DELETE https://gitlab.com/api/v4/projects/11111/issues/54321
Redis.delete(datum)
end
- Create an RSpec formatter to log this data to the Redis server after test run.
- Create a Pipeline Schedule to run this script (it could exist in
quality/toolbox
)- Script doesn't care which environment - it is configured for all. (tokens, etc)
- Depending on the environment, will query a DELETE via the Rest API.
- Script deletes the row from Redis.
- Script could also potentially monitor failures. I.e., in cases where the API DELETE fails.
We could get as granular as we'd like.
{ "resource": "Project", "id": 11111, "env": "gitlab.com", created_at: 2023-01-22, "test": "qa/qa/specs/features/browser_ui/7_configure/auto_devops/auto_devops_templates_spec.rb:27" } // know which test created this resource, where, and when.