Skip to content

Add support for a job-level `run` keyword

The gitlab-ci.yml file must allow the run keyword under jobs. A following issue: Validate steps syntax with JSON schema (#440488 - closed) • Unassigned will add validation (e.g. in the pipeline editor).

When this issue is complete, I would expect to type run: into the pipeline editor and it would be happy (no errors).

I would not expect for the content under run to be validated by the schema, stored in the database, or passed to runner. Those issues come next.

Here are the parts of the epic which are relevant to this issue:

Goals

  1. User can use CI Steps in their .gitlab-ci.yml with a first-class syntax run:.

Design

.gitlab-ci.yml

User would create the following .gitlab-ci.yml that would allow to use steps in existing CI workflows:

hello-world:
  image: registry.gitlab.com/gitlab-org/step-runner:latest
  run:
    - step: ./path/to/local/step-name.yml
    - step: gitlab.com/josephburnett/component-hello-steppy@master
      inputs:
        hello: world

Approach

  • The GitLab Rails would bundle the JSON schema validation in a source code.
  • The GitLab Rails would not parse the run:, only validate...

Related Work

Group Issue Link
backend Create and normalize ci_build_execution_config ... (#453957 - closed)
backend 👈 You are here

Contraint (from discussion)

Yes, we would consume json schema, and validate the entry:

validates :run, json_schema: {
  base_directory: "lib/gitlab/ci/config/entry/schemas/step_runner",
  detail_errors: true,
  filename: "steps",
  hash_conversion: true
}, allow_nil: true

No Entry classes.

Rails would not do anything else with it, it would be forbidden to perform any transformation of the payload. It would be required to pass it as-is to Runner. So, we would serialize the run into ci_builds_metadata.

Edited by Mark Nuzzo