Programming Languages templates to components migration
## Summary
This issue contains the work necessary to migrate selected programming language templates to components.
### Additional tasks
1. Evaluate whether the existing programming language CI/CD templates require updates through migration, or require a creation from scratch.
1. A valid result is that they cannot be converted into a CI/CD component because of their job complexity, or (test) requirements.
2. This research will help users who wonder about missing CI/CD components. They can review the research and discussions in this epic and related issues.
2. Learn which programming language templates we feel confident to maintain and also have the resources available.
## Proposal
To migrate the list below to components. The list selects common programming language templates, and is not complete.
### DevRel focus
based on https://gitlab.com/groups/gitlab-org/-/epics/12066#note_1654990982 and https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates
#### Programming languages
<table>
<tr>
<th>Template</th>
<th>Issue</th>
<th>Migrated by</th>
<th>Done?</th>
<th>Tested by</th>
<th>Owned by</th>
<th>Priority</th>
<th>Notes</th>
<th>Can be migrated?</th>
</tr>
<tr>
<td>
[C++](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/C++.gitlab-ci.yml)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435749
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>Different compilers and build chains. Be opinionated and use best practices env variables (CXX(gcc,clang)), CMake, etc.)</td>
<td>Tentatively yes, but requires more work.</td>
</tr>
<tr>
<td>
[Go](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Go.gitlab-ci.yml)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/437104
</td>
<td>
@dnsmichi
</td>
<td>
https://gitlab.com/components/golang (90%)
</td>
<td>
</td>
<td>
DevRel, @dnsmichi
TODO: engineering (Runner?)
</td>
<td>
</td>
<td>
Needs split jobs, and "super component". Creates dynamic job names based on the input `golang_version`
</td>
<td>Yes</td>
</tr>
<tr>
<td>
Java ([Gradle](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Gradle.gitlab-ci.yml))
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435750
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>Java, OpenJDK, env variables, etc. -- Frameworks: Maven, ..</td>
<td>
</td>
</tr>
<tr>
<td>
Java ([Maven](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Maven.gitlab-ci.yml))
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435751
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
</tr>
<tr>
<td>
[Mono](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Mono.gitlab-ci.yml) (.NET on Linux)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435752
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
</tr>
<tr>
<td>
NodeJS ([npm](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/npm.gitlab-ci.yml))
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435753
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>Different test frameworks and versions (npm, yarn, etc.) -- might need split into templates. NodeJS does not capture web frameworks. Needs to be clearly defined what the component should do</td>
<td>
</td>
</tr>
<tr>
<td>
[PHP](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/PHP.gitlab-ci.yml)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435754
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>PHP CLI, Test frameworks, and frameworks: Lavarel</td>
<td>
</td>
</tr>
<tr>
<td>
[Python](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Python.gitlab-ci.yml)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435755
</td>
<td>
@dnsmichi
</td>
<td>
</td>
<td>
</td>
<td>TODO: DevRel, Engineering</td>
<td>
</td>
<td>Only Python3 supported</td>
<td>
:rocket: Yes
</td>
</tr>
<tr>
<td>
[Ruby](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Ruby.gitlab-ci.yml)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435756
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>Split for and Ruby Ruby on Rails</td>
<td>
:construction_site: No. Needs to be created from scratch https://gitlab.com/gitlab-org/gitlab/-/issues/435756#note_1728754511
</td>
</tr>
<tr>
<td>
[Rust](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Rust.gitlab-ci.yml)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435757
</td>
<td>
@dnsmichi
</td>
<td>
</td>
<td>
</td>
<td>TODO: DevRel, Engineering</td>
<td>
</td>
<td>Add Rust caching (not documented yet)</td>
<td>
:rocket: Yes
</td>
</tr>
<tr>
<td>
[.NET](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET.gitlab-ci.yml)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435758
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>Figure out which .NET (Core) versions can be supported</td>
<td>.NET has evolved over the years. It is not clear to me which .NET versions are supported by Microsoft, and which ones customers are using in their CI/CD systems.</td>
</tr>
<tr>
<td>
[.NET Core](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET-Core.gitlab-ci.yml)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435759
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
</tr>
<tr>
<td>
[MATLAB](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/MATLAB.gitlab-ci.yml)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435760
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>Research whether this can be component</td>
<td>
:x: No, skip for now. Requires test environment.
</td>
</tr>
<tr>
<td>
[LaTeX](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/LaTeX.gitlab-ci.yml)
</td>
<td>
https://gitlab.com/gitlab-org/gitlab/-/issues/435761
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>
</td>
<td>Easiest conversion example (might not fit a component)</td>
<td>
:x: Might better serve in the documentation as learning example
</td>
</tr>
</table>
## Confirm purpose and User Reception (how does this benefit the user?)
As GitLab pushes towards the use of components more than templates in the future, migrating the popular programming language templates to components will help advocate for this process and in turn, increase user adoption for components.
## Additional details
Some relevant technical details, if applicable, such as:
- Does this need a gitlab~7884237?
- Does there need to be an associated gitlab~15980522 issue created related to this work?
- Is there an example response showing the data structure that should be returned (new endpoints only)?
- What permissions should be used?
- Is this EE or CE?
- [ ] EE
- [ ] CE
- Additional comments:
## Links/References
## Requirements
Programming language templates require a different UX. They provide multiple jobs that require splitting the component into multiple templates.
> Before migrating a component, it is required to understand how a component works, how it can be tested, released and published. It is recommended to start learning how to create a component from scratch, following the documentation https://docs.gitlab.com/ee/ci/components/#create-a-component-project Once you feel familiar with inputs and CI/CD job templates, start with the migration.
### Component migration steps
1. Create a components project in your own namespace or group.
2. Start with the [directory structure](https://docs.gitlab.com/ee/ci/components/index.html#directory-structure) to [migrate a component](https://docs.gitlab.com/ee/ci/components/#convert-a-cicd-template-to-a-component).
3. Split each job into a separate template, and provide a full pipeline job which captures the following file structure:
```plaintext
templates/
lint.yml
build.yml
test.yml
full-pipeline.yml
```
2. Add a `.gitlab-ci.yml` which includes the components and tests them.
1. This requires source code additions to the repository, i.e. main.go for Golang and corresponding file structure.
3. Add a LICENSE.md file (MIT)
4. Add a README.md with the `Usage` , `Inputs`
5. Add problems, findings, challenges into the assigned issues, and epics table.
1. Stop migrating templates if they cannot be reliably moved into a component.
### Example: Golang
https://gitlab.com/components/golang follows the structure above and should be used as a reference implementation.
### Review and release
1. Start with 0.x.y releases while implementing the migrated templates.
1. Add a README.md note that the component is not ready for production yet. Example: https://gitlab.com/components/golang/-/blob/9adb9e5acbb7b0bce1c79d9773126a3adb940267/README.md#L3
2. Create an issue in the component project, tracking 1.0.0 release
1. Address review feedback from the issue listed in the epic.
2. Integrate the components toolkit when ready
3. Example: https://gitlab.com/components/golang/-/issues/2
3. Create issues for follow-up tasks
4. Ask CI/CD components maintainers to determine whether GitLab should maintain the component in the gitlab.com/components namespace
1. This is optional.
2. Maintainers can migrate/fork the component project into the GitLab maintained namespace.
3. Original authors need to be documented in the README.md file.
### Optional changes after migration
Add best practices:
1. Caching
2. Code coverage configuration and Junit test reports (opinionated)
epic