Why does Gitlab CI not show job-level variables in the Run Pipeline web UI?

GitLab CI/CD
1

I want to modularize my project’s pipeline jobs into multiple child workflows. I do this because creating one huge .gitlab-ci.yml file at the project root with all the jobs is a readability and maintenance disaster. However, the Gitlab CI’s UX is a massive spanner in the works.

I have a number of jobs like the following which would normally run automatically (on merge requests, push to main branch, scheduled, api). However, I’d also like to provide the team’s developers an option to manually trigger them from the web UI passing custom variable values to the job.

In this example, I’d like the variables RUN_MY_JOB, JOBS_VARIABLE_1, JOBS_VARIABLE_2 to be specified from the “Run Pipeline” web UI.

my-job:
  stage: build
  trigger:
    include: .gitlab-ci/child-job/.gitlab-ci.yml
    strategy: depend
  rules:
    - if: >
        $CI_PIPELINE_SOURCE == "web"
        && $RUN_MY_JOB == "true"
      variables:
        JOBS_VARIABLE_1: ???
        JOBS_VARIABLE_2: ???
    - if: >
        $CI_PIPELINE_SOURCE == "merge_request_event"
        && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    # ... other conditions on which this job runs ...

However, presently this only works if the user manually enters both the variable name and its value in the web UI while triggering the pipeline. This requires the user to visually scan the .gitlab-ci.yml to determine the variable names and then correctly enter them in the web UI.

Some additional usability problems are:

  1. Gitlab CI doesn’t warn the user if there’s a typo in the variable name or if a required variable is skipped.
  2. Gitlab CI doesn’t provide an option to provide a description for the variables, so the user needs to “guess” what the variable does, or read through the workflow to figure it out.
  3. The above example is not even valid syntax because it’s not clear what should replace the ???. I do not want any “default” values for these variables, only to declare that this job requires those variables.

The official documentation only gives a handwaving statement:

Job-level variables cannot be pre-filled.

Why does Gitlab CI not allow job-level variables to be pre-filled? Why are these usability issues not considered important at Gitlab?

2

I’m very new to Gitlab, but trying to migrate from Jenkins. In parameter passing at least Gitlab Runners seems inferior. I was looking at the possibility of using different schedules with an execution date way in the future to customise my parameters. Yes it’s a hack, but still.