Proposal: Build and release stage
Context
Right now, Runway is a deployment engine for CI/CD. In the original blueprint proposal, a container image was defined as the contract between service project and deployment project:
R120: Programming-language agnostic: no requirements for services. Services should be packaged as container images.
In practice, packaging a container image can be a barrier to entry for simple or greenfield services.
Proposal
Extend Runway to both package and deploy container images. Here’s an illustrative example pipeline:
By supporting both packaging and deploying container images, service owners can focus on writing and deploying code much quicker. Cloud Run would still be leveraged for deployments.
Functionality
By leveraging existing CI templates in Runway, we could provide the following functionality:
- Automatically build container images when
Dockerfile
present - Automatically push container images to GitLab Container Registry
- Automatically scan container images for vulnerabilities, secrets, etc.
Benefits
- Standardize on packaging containers at GitLab w/ CI templates, e.g. kaniko vs dind
- Ensure best practices for packaging containers, e.g. scanning, tagging, caching, etc.
- Remove friction for onboarding new services, e.g. simple stateless services, serverless functions, etc.
Trade-offs
- Adds complexity by supporting multiple onboarding paths (i.e. build vs bring your own image)
- Distracts from focusing on improving Runway's deployment engine by expanding too soon