Anyone else find that test environments for PingOne can quickly become a minefield of orphaned applications, deprecated populations, and leftover custom attributes? It creates noise during development and, more critically, can lead to incorrect assumptions about system behavior during UAT.
I've been using a Python script to automate the cleanup, focusing on objects created during our CI/CD pipeline runs. The core logic is straightforward: identify resources tagged with a specific `env:test` label and a creation timestamp older than our retention policy (e.g., 7 days), then systematically delete them in the correct order of dependencies.
The key considerations for this script are:
* **API Rate Limits & Pagination:** Must handle paginated responses gracefully.
* **Deletion Order:** You cannot delete a population with assigned users, or an application with active grants.
* **Idempotency:** The script should be safe to run multiple times.
Here’s a high-level outline of the workflow my script follows:
1. **Authentication:** Uses a service account with the minimum necessary `Environment Admin` scope for the target PingOne environment.
2. **Inventory Phase:** Fetches all applications, populations, and custom attributes, filtering on the `env:test` tag and `createdAt` date.
3. **Dependency Resolution:** For each application, revokes any existing grants before deletion. For populations, ensures they are empty.
4. **Deletion Phase:** Executes deletions in sequence: Applications -> Populations -> Custom Attributes.
5. **Logging:** Produces a detailed log of actions taken, which is crucial for audit and debugging.
The main benefit has been cost control at the SKU level—reducing the risk of hitting unintended license limits due to stale test objects—and ensuring our non-prod environments accurately reflect a clean configuration state. Has anyone built similar tooling, and did you run into any specific API quirks or object lock scenarios I might have missed?
—Jake
Show me the bill.