Simplify serverless.yml format
provider: name: gitlab/knativeand make it a default.
- Users can still specify
provider: name: triggermesh.
gitlab/knativeproviders are valid.
Simplify how we define a runtime, support non-URL runtimesExtracted to https://gitlab.com/gitlab-org/gitlab-ce/issues/61172
GitLab-provided runtimes can be defined withExtracted to https://gitlab.com/gitlab-org/gitlab-ce/issues/61172
Full-URL runtimes are still supportedExtracted to https://gitlab.com/gitlab-org/gitlab-ce/issues/61172
- Rename / alias
- Rename / alias
But this makes a lot of things more complex, and, in my opinion, it affects evolution of GitLab Serverless features in a negative way. We need more flexibility, and we need to have ability to hide complexity of Serverless in a correctly.
Example: how would GitLab CI/CD evolve if we had to support syntax from
- We need to hide complexity of Knative, Kubernetes and Serverless in general. We need good tools and some flexibility to build proper abstractions. Depending on 3rd-party configuration files is going to make it much more difficult.
- Serverless Framework is much more abstract and generic than what we are trying to build. We probably don't need 90% of configuration options that Serverless framework provides.
- Keeping our
serverless.ymlcompatible with Serverless framework might be cumbersome in the context of backwards compatibility, vendor lock-in, and catch up on changes in the framework.
- If we stick to Serverless framework syntax, we will not be able to leverage our knowledge that stems from experience with designing
- We strive to be Serverless landscape innovator. 3rd-party config files and coupling to 3rd-party frameworks (that are not necessary to do the job) can make innovation more difficult.
I believe that we should not care about making
serverless.yml compatible / similar to what Serverless framework offers.