GitLab CI/CD Suggested / Required Variables

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Release notes

Problem to solve

I often have projects that I want to run jobs in manual stages with some user input. For example, one project has a job for a Google Chrome extension release. I want to be able to allow my release manager to pick whether the release is a MAJOR, MINOR or PATCH release, so the auto-versioning system can increment accordingly. I have a $LEVEL variable that they can use, but this requires them to manually type the variable in to the Manual job system.

Proposal

It would be great if the .gitlab-ci.yml could specify variables that are suggested and/or whether they're required. Even better if we can have an "enum" type to pick options from.

My proposal would be to extend the variables keyword of .gitlab-ci.yml. This keyword already works globally and per-job. An example would be:

variables:
  suggestions:
    LEVEL:
      required: true
      type: enum
      allowCustom: false
      options:
        - MAJOR
        - MINOR
        - PATCH
    API_ENDPOINT:
      required: false
      type: text
      default: https://api.mycompany.com
    RELEASE_NOTES:
      required: true
      type: largetext
      default: "Type your release notes here"

Wherein:

• variables is an object, as it currently stands
• ... with an override on the suggestions keyword, that itself is also an object
• ... where the key is the variable and the value is an object, supporting:
  • required: whether to deny running the job without the variable being set
  • allowCustom: when options is used, whether or not a custom typed-in value is allowed
  • options: an array of strings that give options to be picked from
  • default: a default value that is present on the manual job screen but editable

Intended users

This is intended primarily around Release Managers - it allows the devops team to communicate requirements to them during release without needing to resort to jobs simply failing with a note to the release manager on the variables they missed [as we do currently]