UI misses some settings such as dockerfile_path. Monorepo applications are trendy right now so we cant have single Dockerfile in root of repo. Rather we have DockerfileAdmin, DockerfileShop in .projects/admin and ./projects/shop etc..
But even if UI did have all the features, we prefer to have app.yaml pulled from the repo because of version control, easy and deterministic rollback in case of issues etc.
To answer question 1. Even though we run jenkins right now and we could
dooctl apps create --spec <path-to-spec> , the end goal for us was to ditch CD part of pipeline and rely on DigitalOcean App Platform to do the heavy lifting and build and deploy everything based on provided Dockerfile.
Finally after careful consideration we decided App Platform does not meet our needs so we are moving back to droplets.
The main reasons are:
- Pull not possible from tag. Only branch
- Rollback to previous docker tag not possible
- app.yaml specification not connected to actual build process (
- Connecting to managed database not possible with firewall rules
App Platform is very promising with great features such as direct console, monitoring, cdn, ease of deployments (only if case is trivial though. We were unable to setup multi language angular APP to compile only once and deploy both languages as single or two static sites. We were more than happy to pay double but were unable to find a solution)
Final suggestion. Most of these issues could be solved if App Platform would just save docker images to private repo that customers would gladly pay. If i provide Dockerfile dont just build the image and then discard it. Make it possible to save to DOCR so we get rollback functionality.
The inherent risk with not having deterministic rollback functionality and amount of customization we had to make and significantly higher price for App Platform for the same or similar resource we decided to wait a little bit longer.
Sorry for long post