Summary
Expose the "force delete" capability that currently exists only in the Sprintr UI as an endpoint (or flag on the existing `DELETE` endpoint) in the Deploy API v4, so environments stuck in a broken state can be removed programmatically.
Problem / Motivation
When automated app deployments via the Deploy API fail, environments are sometimes left behind in a state that the regular `DELETE` endpoint cannot resolve. Today the only way to clean them up is to open the Sprintr UI and use the "force delete" option, which requires several manual clicks per environment.
This is particularly painful for automated integration tests and CI/CD pipelines: every failed test run can leave behind stale environments that have to be removed by hand. Recently I had to delete multiple environments one by one through the UI for exactly this reason which doesn't scale and defeats the purpose of an automated pipeline.
Proposed Solution
One of the following would solve this:
- A new endpoint, e.g. `DELETE /api/v4/apps/{appId}/environments/{environmentId}/force`
- Or a query parameter / request body flag on the existing endpoint, e.g. `DELETE .../environments/{id}?force=true`
Behavior should mirror the UI's "force delete" exactly: remove the environment regardless of its current state, without requiring it to be in a healthy condition first.
Benefit
- Fully automated CI/CD cleanup, no manual UI steps
- Self-healing test pipelines (cleanup as part of teardown)
- Consistent API surface anything doable in the UI should be doable via the API
Thanks for considering!
Best regards,
Marvin
@Feddo van Ede
Is it possible to clear an environmet via the API? Couldn't find anything on the docs Mendix on Kubernetes Deploy API | Mendix Documentation
Hi Feddo,
Not quite.
We spin up throwaway environments automatically for our CI/CD and integration tests, then tear them down again afterwards. When a deploy fails, some get stuck in a broken state that the normal API DELETE won't remove, and the only fix is "force delete" in the UI, one at a time. That doesn't scale for automated teardown.
So the ask is to expose that same force delete in the Deploy API v4, either as its own endpoint or a force=true flag on the existing DELETE.
Best,
Marvin