Skip to content

Refactor CI interpolation input classes

Fabio Pitino requested to merge fp-refactor-interpolation-inputs into master

What does this MR do and why?

This MR refactors how we build input objects from both spec:inputs specifications and user-provided values.

Before this refactoring we had different types of inputs based on various characteristics of input specification:

  1. Default if default was defined
  2. Required if default was not defined
  3. Options if options was defined
  4. Unknown for catch all scenarios

The main problem with this object classification is the fact that options can be specified together with default and the 2 characteristics are not mutually exclusive. Currently options does not work and it's not even enabled as syntax but the design would need to be changed anyway when we enable options attribute of the input spec.

Also the Unknown type was there just as a catch all type but it wasn't necessary.

After this refactoring we consolidate the characteristics (required, with default, options) under a single Interpolation::Inputs::BaseInput class so that all types of inputs always behave the same under this aspect. The new class also has a smaller interface (less public methods).

We also introduce a type StringInput class which is the default type today. Adding new types is now very easy and it requires to add a new class with only 2 class methods:

class Gitlab::Ci::Interpolation::Inputs::BooleanInput < Inputs::BaseInput
  def self.matches?(spec)
    spec[:type] == 'boolean'
  end

  def self.valid_value?(value)
    [true, false].include?(value)
  end
end

All validations are equivalent to StringInput (and other future types):

  • check that the selected input type is supported
  • check that the value is provided, if there is no default specified
  • check that the provided value matches the given type
  • check that any default value matches the given type

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports