Simplify serverless.yml format
Proposal
- Add
provider: name: gitlab/knative
and make it a default. - Users can still specify
provider: name: triggermesh
. - Only
triggermesh
andgitlab/knative
providers 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/61172runtime: gitlab/runtimes/a-runtime-name
-
Full-URL runtimes are still supportedExtracted to https://gitlab.com/gitlab-org/gitlab-ce/issues/61172 - Rename / alias
env-secrets
tosecrets
. - Rename / alias
environment
toenvs
.
Old description
We currently try to be compatible with Serverless framework in terms of `serverless.yml` syntax.
*This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*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 .travis-ci.yml
?
My points:
- 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.yml
compatible 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
.gitlab-ci.yml
. - 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.
Edited by 🤖 GitLab Bot 🤖