Hi, @maxhodak. All deploys can always be deleted. You must delete the site to do this but it is always possible to do so.
To prevent downtime, you can spin up a new version of the site and move any custom domains to the new site before deleting the original.
You can also always use two sites. The production site with no deploy previews and a second site linked to the same repo where you do allow deploy previews. The second deploy preview site could then be deleted from time to time to clear up the old deploy previews without impacting the production site in any way.
No one will argue that being able to delete individual deploys would be better but it is untrue that deploys cannot be deleted. All deploys can be deleted which means the statements above about security issues and GDPR violations are also untrue. You can always delete deploys.
About this:
It’s honestly pretty outrageous that this has stayed open for so long in this way
While I do understand why you have that opinion, I don’t think it is outrageous at all. There are reasons why this change is happening slowly.
In my time working in enterprise software development I have come to understand that technical debt is all too real and reworking early fundamental design choices is the trickiest of all technical debt to handle.
The early design choices in this case were that deploys would be atomic and immutable and there is a blog post about that very topic here:
The decision to make deploys immutable also led to the decision that deploys cannot be deleted the site itself is deleted (as deleting a site deploy is changing it and changing things isn’t allowed for immutable objects). Since the time these design decisions were made, a huge amount of code was written that relies on the deploys not being deletable. There are certain efficiencies to be gained when you can count on deploys always existing until the site is deleted. The code that was written took advantage of those efficiencies.
We are also going to have the make the changes on a live service without breaking anything. So, huge changes must be made, in parallel, to many interconnected software systems while keeping all the existing sites working and all currently running builds deploying. This will require extensive testing and a coordinated rollout of the changes.
So, making this change far from being as simple as just making an API call to delete deploys and adding a button in the UI to trigger it. There are a number of interdependent systems that will all require fundamental changes to their design to allow deploys to become deletable. That work is non-trivial in terms of both the complexity of the changes required and the number of person hours of work required to make the those changes.
I hope this clarifies that we are working on this feature and why those changes are slow in arriving.
You also stated that the URLs are predictable which true; they are predictable by design.
Would you be willing to explain more about how would you prefer they worked instead? Would all deploy preview URLs be random? Would the site subdomain (which is currently part of the URL) continue to be used?