Dedicated GitLab Serverless runtimes
Problem to solve
GitLab Serverless currently uses Triggermesh runtimes and knative build. Knative build will soon be sunset and replaced with Tekton. Tekton is a young product and lacks some of the functionality we'd like to include in our serverless product such as easy access to logs for troubleshooting, easy usage of env variables, etc. To provide a better serverless experience to end users we want to bring knative builds to GitLab CI. In order to bring serverless builds to GitLab CI we will have to use runtimes that are more generic and not specific to knative-build (ie, make use of build templates).
Further details
Proposal
Create or reuse existing runtimes that support our goals and include:
- node.js
- ruby
- dockerfile (via kaniko)
Once runtime implementation is decided upon, this will inform how the CLI should function https://gitlab.com/gitlab-org/gitlab-ce/issues/58058.
Some existing considerations include:
- AWS Lambda runtimes
- Serverless framework runtimes
- Triggermesh KLR (different from existing runtimes)
- Openfaas
- Project Riff
Selected Runtimes
We have decided to base our runtime on existing node.js and Ruby runtimes in order to move forward. This will allow us to reduce the runtimes to only the minimum requirements of GitLab serverless CI (using gitlabktl
) as this is the smallest and most reasonable iteration forward. Having a ruby runtimes will allow us to dogfood internally and surface further requirements for GitLab Serverless.