Migrate GitLab-Maintained Template to Components

Background

• In %16.6, we’ve announced the Beta release of the CI/CD components ✅
• In %16.7, we've announced the Beta release of CI/CD catalog ✅

Our vision for the catalog is to be a single location where users can access and consume CI/CD related offerings (Components, Steps, etc…)

We would like to encourage our users to move away from Templates to Components, today we have ~100 different GL-maintained templates which would need to be converted into components and published

Process

You can watch a video of a refactoring from CI template to CI component: https://www.youtube.com/watch?v=dGCPrIAuBmE

1. Pick a template to convert (from the list below or a dependency of the templates below).
2. Convert the template to components
3. Decide whether the component should have its own project or whether multiple components should be bundled together in the same project. Example: Code Quality is a good example of a project just containing that component. AWS could be a project hosting multiple components from AWS-related templates.
4. Create a project in https://gitlab.com/components or ask @fabiopitino to assist if any problems.
5. Follow the conversion docs.
6. Ensure that the component could be eventually reused where currently the template is used (e.g. in the Auto-Devops template). No need to replace the template with the component because it would break self-managed instances. We only need to ensure it COULD be replaced eventually, for example that that all required inputs are defined.
7. Get the whole project reviewed by @fabiopitino and another member of grouppipeline authoring.
8. Release and publish the component project in the catalog.
9. Determine the ownership and maintenance of GitLab-maintained CI Components after creation.

List

List of popular templates (based on https://app.periscopedata.com/app/gitlab/785953/Pipeline-Authoring-Dashboard?widget=13440051&udv=1204805)

Template	Issue	Migrated by	Done?	Tested by	Owned by
ADO	#433263		Convert this at the end, when all dependencies are done		groupenvironments
SAST		@fabiopitino	✅ https://gitlab.com/components/sast	groupstatic analysis	groupstatic analysis
Code-Quality		@fabiopitino	✅ https://gitlab.com/components/code-quality	groupstatic analysis	groupstatic analysis
Helm-2to3	#433262				groupenvironments
Code-Intelligence	#433261				groupcode review
ECS		@fabiopitino	⚠ https://gitlab.com/components/aws	help needed	groupenvironments
EC2		@fabiopitino	⚠ https://gitlab.com/components/aws	help needed	groupenvironments
Test	#433265 (closed)	@f_caplette	README needs to be created	help needed	groupenvironments
Build	#433266 (closed)	@lauraX	README needs to be created	help needed	groupenvironments
Dependency scanning	#433267 (closed)	@Kasia_Misirli			groupcomposition analysis
license_scanning	#433268 (closed)				groupcomposition analysis
DAST or DAST.latest understand which to convert	#433691	@avielle			groupdynamic analysis
DAST-Default-Branch-Deploy	#433269	@avielle			groupdynamic analysis

DevRel focus

based on &12066 (comment 1654990982) and https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates

Programming languages

See #435740 (closed)

Container images, Security, Mobile

See #435743 (closed)

How to test

Each component project should have a .gitlab-ci.yml in it that includes the components defined in the project. See an example here: https://gitlab.com/components/aws/-/blob/main/.gitlab-ci.yml?ref_type=heads.

• The basic goal (required) is to include the components and get the pipeline pass.
  • Some pipelines may be failing because of missing pre-requisites.
  • We need to ensure that jobs included with the component are executed successfully.
• We also recommend (whenever possible) to have jobs in .gitlab-ci.yml that verify the side-effects introduced by the component. For example: if a component generates Code Quality report, in a subsequent job in the pipeline we check that a report artifact is created correctly.