## Epic This Epic describes all work required to achieve CI Steps [MVC](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc): - The proposed MVC is complete, and provides the most minimal set of functions to enable composable steps execution. - The presented YAML syntax is subject to change during problem refinement and development. - To understand proposed MVC design choices get familiar with [CI/CD Components design](https://docs.gitlab.com/ee/ci/components/#components-repository). - This delivers aspects of the [Step Runner to execute GitLab Steps](https://docs.gitlab.com/ee/architecture/blueprints/gitlab_steps/). - This incorporates discussion from [Step Runner Implementation Details MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/131688). ## Objectives 1. **Use**: 1. User can use CI Steps in their `.gitlab-ci.yml`. 1. User can run `steps` locally by passing them via command-line. We would not yet parse `.gitlab-ci.yml`, as we would require to use `$STEPS` environment variable. 1. **Share**: 1. User can write it's own CI Steps and store it in the current repository. 1. User can fetch externally stored CI Steps from GitLab repository. 1. **Workflow**: 1. The `step.yml` would support two functions: execute a binary in a structured form, or sequence of steps. 1. The `step.yml` can be configured with the inputs. We would implement syntax support for the `${{ inputs.input_name }}`. We would initially support only `type: string` for inputs. ## Outcome 1. **User facing**: as an requirement to reach to customers for the feedback: 1. User can use and integrate steps into current workflow. 1. User can write its own step, share (on GitLab), and easily test them locally. 1. The `step-runner` project is bootstrapped, and published to container registry to easily be included. 1. User can create their own `step-runner`-enabled image following the documentation provided by the project. 1. Any existing user of GitLab CI/CD can try (including us) to write the very first step following documentation. 1. **Development**: as an requirement to add more people to develop this project: 1. The Step Runner architecture, compiled, tested and published. 1. The main data structures are established (in form of protobuf) that can be used and shared to other projects. 1. The testing container image to use Step Runner is managed, and published as part of the CI, and can be pulled into existing pipelines. ## Design #### .gitlab-ci.yml User would create the following `.gitlab-ci.yml` that would allow to use steps in existing CI workflows: ```yaml hello-world: image: registry.gitlab.com/gitlab-org/step-runner variables: STEPS: | - step: ./path/to/local/step-name.yml - step: gitlab.com/josephburnett/component-hello-steppy@master script: - /step-runner ci ``` ### Write local step with usage of `spec:inputs`, and referencing other steps User would create a local file under `./path/to/local/step-name.yml`. ```yaml spec: inputs: name: description: Who do you want to greet? default: steppy --- steps: - step: gitlab.com/josephburnett/component-hello-steppy@master inputs: hello: "world ${{ inputs.name }}" - step: gitlab.com/josephburnett/component-hello-steppy@master ``` The local step would be referenced by usage of `./` prefix to step location. ```yaml steps: - step: ./path/to/local/step-name.yml ``` ### Use step from GitLab repository User would store a shared step using the following directory structure: ```yaml ├── README.md ├── .gitlab-ci.yml ├── steps/ ├── ├── sast.yml │ └── dast │ └── step.yml ``` The step would be referenced by using FQDN name to reference GitLab from which Steps would be fetched. ```yaml steps: - step: gitlab.com/josephburnett/component-hello-steppy@master ``` The steps would be executed the same as a locally written step. ### Write a step executing binary command in a structured form User would create step in a place of his/her choice (local or in git repository). Executing binary would be done using syntax similar to the below: ```yaml spec: inputs: name: description: Who do you want to greet? default: steppy --- exec: command: [/path/to/command, arg1, arg2, arg3, arg4] env: VARIABLE: value HELLO: "world ${{inputs.name}}" ``` ## Competencies required - Golang engineer