feat: add cleanup process for sunsetted collections#1284
feat: add cleanup process for sunsetted collections#1284yelizhenden-mdb wants to merge 3 commits into
Conversation
yelizhenden-mdb
force-pushed
the
CLOUDP-260980
branch
from
30ff6c2 to
bd89450
Compare
yelizhenden-mdb
changed the title
yelizhenden-mdb
changed the title
yelizhenden-mdb
force-pushed
the
CLOUDP-260980
branch
from
bd89450 to
76dfcfd
Compare
yelizhenden-mdb
force-pushed
the
CLOUDP-260980
branch
from
76dfcfd to
1d1c840
Compare
yelizhenden-mdb
requested review from
andmatei,
andreaangiolillo,
drinkbird,
maks-m-mongo-leaf,
matt-condon,
saisundar and
wtrocki
| # Delete all previous Atlas Admin API collections from the workspace. | ||
| # The current collection is excluded by name — it was either just created (not in the | ||
| # initial list) or matched by name in the update case. | ||
| deleted=0 | ||
| while IFS= read -r row; do | ||
| id=$(echo "${row}" | jq -r '.id') | ||
| name=$(echo "${row}" | jq -r '.name') | ||
| echo "Deleting old collection: ${name} (id: ${id})" | ||
| echo "curl --request DELETE --location 'https://api.getpostman.com/collections/${id}' --header 'X-API-Key: **********'" | ||
| http_code=$(execute_curl --silent --show-error \ | ||
| --write-out "%{http_code}" \ | ||
| -o /dev/null \ | ||
| --request DELETE \ | ||
| --location "https://api.getpostman.com/collections/${id}" \ | ||
| --header "X-API-Key: ${POSTMAN_API_KEY}") | ||
| if [[ "${http_code}" != "200" ]]; then | ||
| echo "[ERROR] Failed to delete old collection: ${name} (id: ${id}), HTTP status: ${http_code}" | ||
| else | ||
| deleted=$((deleted + 1)) | ||
| fi | ||
| done < <(jq -c --arg current "${current_collection_name}" \ | ||
| '.collections[] | select(.name | contains("MongoDB Atlas Administration API")) | select(.name != $current)' \ | ||
| "${COLLECTIONS_LIST_FILE}") | ||
| echo "[SUMMARY] Deleted ${deleted} old collection(s)" |
There was a problem hiding this comment.
is this a breaking changes for customers using that collection? Do you remember the reasons why we decided to rename the collection?
There was a problem hiding this comment.
The customers always must use the latest collection. Can you think of any use case a customer might need to use a previous collection?
This PR does not introduce any renaming, it is just cleaning up the previous collections
There was a problem hiding this comment.
Can you think of any use case a customer might need to use a previous collection?
I don't have enough context on how we generate the collection. In particular, it would be helpful to understand how we handle deprecated versions. Are we removing them from the collection and requiring customers to move to the new API version? If so, one use case for keeping the old collection available would be to let customers continue using the deprecated endpoints until they've fully migrated.
This PR does not introduce any renaming, it is just cleaning up the previous collections
Got it. My question is more along the lines of: if a customer is currently using any of the collections you're planning to delete, will they encounter an error? If so, that wouldn't be a great experience, and I'm wondering if that was the reason we chose to rename the old collection when we worked on Postman instead of deleting them.
There was a problem hiding this comment.
Valid concerns. Here is my understanding of how this works:
- The collection is generated from the latest FOAS (
openapi-YYYY-MM-DD.jsonfile). Deprecated endpoints will still be included as long as they haven't been sunset - If a customer forks the collection, it persists locally and independently, so deleting the source will have no impact. If a customer references the collection directly by URL or ID, deletion could cause an issue
- I implemented the star feature as well. The original requirement was just to make the latest collection more prominent. I haven't been asked to remove the older ones, or that option wasn't considered at the time
Also, to ensure I didn't misinterpret the ticket, I'm going to sync with Stephen to confirm this PR aligns with what he wanted. Thanks for calling this out!
2 participants
Proposed changes
Jira ticket: CLOUDP-260980
Problem
Every time a new Atlas Admin API version is released, a new Postman collection is published but the old one is only renamed (⭐ removed) and left in the workspace. Over time, this accumulates redundant collections that create noise for customers browsing the workspace.
The Postman collection is generated from the latest FOAS, which contains all endpoints across all API versions. Customers select the API version they want via the Accept header, not by choosing a different collection. Old collections don't provide any additional endpoint coverage.
What changed
tools/postman/scripts/upload-collection.shThe cleanup runs after every upload. Because the initial collection list is fetched before the new collection is posted, the current collection is safely excluded by name regardless of whether it was just created or updated in place.
Testing
Created new test collections with old versions on Postman:
After running the script, successfully confirmed the old collections are removed:
Checklist
Changes to Spectral
Further comments