<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ### Background The Pipeline editor is our one-stop-shop for GitLab CI, in order to improve the authoring experience for new and novice users we would like to support them as they write or update their CI pipeline. ### Problem GitLab CI could be intimidating to a technical and non technical users, In order to work with GitLab CI users needs to be familiar with YAML which is error-prone, In addition GitLab CI is highly flexible but with this flexibility comes a level of complexity, there are many keywords and ways to implement Pipelines ### JTBD 1. When writing a CI pipeline I would like to know what are the available keywords, so I can use the ones I need. 1. When using at a keyword i would like to know what this keyword is doing, so I can build the pipeline i need. ### Proposed solution 1. Provides our users with an Auto-complete functionality in the pipeline editor when writing pipeline. * Provide our users with the available keyword * Reduce typos and errors in keyword 1. Keyword description when hovering over keyword * Users can get themself familiar with each keyword 1. The ability to add a link keyword to our doc * Users can read more about the available functionality for that keyword ### Suggested design  ### Solution today In the gitlab UI today we are using a JSON schema hosted by a third party to provide feedback and validation to the `.gitlab-ci.yml` file in the editor, the feature is behind FF for self-managed and available by default for the .com version only ## Proposal GitLab should provide an officially available version of the `.gitlab-ci.yml` schema available inside of the GitLab application at a URL accessible by other tools that may want to read this file. and lifting the FF so self-managed customer will be able to use this feature There are two primary benefits to providing: 1. Tools and services inside of GitLab won't need to communicate with an external resource. This provides increased security and better support for environments that don't have internet access. 1. The community can continue to update the [schema on Schemastore](https://github.com/SchemaStore/schemastore/blob/master/src/schemas/json/gitlab-ci.json) (or other 3rd party) based on updates to the official GitLab hosted schema. 1. We should also consider contributing this schema upstream so it could replace the json schema in schemastore and users that are using external editors could potentially benefit from its use ## Out of scope The schema will not do any types of validation, we have a dedicated solution for that in the form of the linter and its API's ## What have we done so far? We run 2 spike issues (Backend and Frontend) and comeup with the following implementation plan 1. Move the schema to be our own file in the repository instead of a 3rd party * Automatically regenerating the GitLab CI config language schema whenever the CI config is changed 1. Fix the IntelliSense for autocompletion of CI keywords (image, after_script, etc) ~frontend 1. Implement the suggestions for all CI keywords ~frontend + ~backend . We would want the values of the keywords to come from the API to make sure they are always in sync (this is to get things like `when: never`) 1. Make suggestions positional only for script, when, etc.