Since the launch of the new automated builds system for Docker Cloud all the way back in Mar 2016, I believe it’s been impossible to create new repositories that use classic automated builds. That’s completely fine, as I have found the new automated builds system to be a fully functional replacement. It does mean that I have a handful of new repositories that can only use the new system, and a bunch of old repositories that have used classic builds. I’ve been attempting to manually convert all old repositories to use the new automated builds configuration so they can all be consolidated on the new system, working the same way.
I have been able to do this successfully across all of my repositories, however, the new Docker Cloud UI does not allow you to delete the last remaining class build rule. As a workaround, I thought I could just create a new rule configured to only trigger on a nonexistent branch name, and thus, never actually be triggered. Unfortunately, I’m still seeing builds for that rule being triggered on any push to the linked GitHub repository. These always fail of course, and result in failed build notifications being sent out, and failed builds accumulating in the timeline.
Related to this, weren’t the classic builds supposed to be automatically converted over at some point? I haven’t seen any announced date for the retirement of classic builds.
The only available solution I’ve found to resolve this right now is to actually delete the entire repository, and re-create it from scratch again. This appears to delete the classic automated build configuration (or at least disassociate it), allowing me to end up with a repository that only has the new automated builds configuration.
Of course, deleting the entire repository is highly destructive, loses all community stars and download counts, and leaves users of that image without access for a period of time while images are rebuilt and pushed up. I can’t afford to do that with all repositories that have classic builds setup.