With the new decisions added to the [blueprint](https://gitlab.com/gitlab-org/gitlab/-/blob/7abed8589104dd1a2479b12097e0d53892487c19/doc/architecture/blueprints/ci_pipeline_components/index.md) about the directory structure we have all the pieces to start working on an MVC for components. ## Problem to solve As a user I want to create components in a project following the directory structure and guidelines in the blueprint. Then I want to consume these components in my `.gitlab-ci.yml`. ## Details In this phase it's not required for components to be published to a Catalog. It's sufficient for the user to know the full path of the component to use. ## Proposal Introduce `include:component` syntax that behaves similarly like other include types. It will automatically [support `with:` inputs ](https://gitlab.com/groups/gitlab-org/-/epics/9530) once they are available. ```yaml include: - component: org/my-project@main - component: org/my-project/my-component@main ``` * For `org/my-project@main` we fetch the file `template.yml` in the root directory for the HEAD SHA of `main` branch. * For `org/my-project/my-component@main` we fetch the file `template.yml` in `my-component` directory for the HEAD SHA of `main` branch. Version qualifiers to support are: - `@<sha>` - `@<tag_name>` - `@<branch_name>` These qualifiers are ordered by precedence based on the [decision in the blueprint](https://gitlab.com/gitlab-org/gitlab/-/blob/7abed8589104dd1a2479b12097e0d53892487c19/doc/architecture/blueprints/ci_pipeline_components/index.md#the-component-version). Before merging the resulting YAML from a component we should check that the YAML, which is going to be merged with the main `.gitlab-ci.yml`, does not contain any of the following top-level keywords: `default`, `variables`, `stages`. These keywords are anti-patterns in the design of components because they would leak settings to other jobs in the pipeline. Change should be made behind a ~"feature flag".