Simplify serverless.yml format

Proposal

  1. Add provider: name: gitlab/knative and make it a default.
  2. Users can still specify provider: name: triggermesh.
  3. Only triggermesh and gitlab/knative providers are valid.
  4. Simplify how we define a runtime, support non-URL runtimes Extracted to https://gitlab.com/gitlab-org/gitlab-ce/issues/61172
  5. GitLab-provided runtimes can be defined with runtime: gitlab/runtimes/a-runtime-name Extracted to https://gitlab.com/gitlab-org/gitlab-ce/issues/61172
  6. Full-URL runtimes are still supported Extracted to https://gitlab.com/gitlab-org/gitlab-ce/issues/61172
  7. Rename / alias env-secrets to secrets.
  8. Rename / alias environment to envs.

Old description

We currently try to be compatible with Serverless framework in terms of `serverless.yml` syntax.

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

*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.*
Edited by 🤖 GitLab Bot 🤖