Docs

# Version 1 (legacy)

Version 1 of the .forms.yml file is the original version, which allowed us to start having the forms.

However, that format proved to have some limitations, which were difficult to work around for the evolution of the functionality. Despite this, the V1 is still compatible with the solution, but it won't benefit from the futures features, which rely on the new format.

So while migrating to upper versions isn't required, we highly recommend it.

# Migration from V1 to V2

To migrate manually from V1 to V2 you need to create the different use-cases, sections, groups based on the previously given examples. Originally the V1 would be composed of maps, whereas now it is composed of arrays. This allows the order to be preserved, and the available features from the V2 onwards.

The name of the sections which were imposed and related to technologies are now free to pick, and the technology has been moved inside the group's definition. For the rest, the name of the key from the map, are now elements of each array under the name attribute.

The entities' definitions have been left untouched.

Example of pseudo-file in V1:

use-caseA:
  ansible:
    group1:
      - definition of var1
      - definition of var2
      - definition of var3
1
2
3
4
5
6

Example in V2:

use_cases:
  - name: use-caseA
    sections:
      - section: <your-new-name-here> # by default will be the previous one, so 'ansible'
        groups:
          - name: group1
            technologies: [ansible] # previously the section/technology name
            vars:
              - definition of var1
              - definition of var2
              - definition of var3
1
2
3
4
5
6
7
8
9
10
11

# New from V2

  1. File's order is preserved

  2. Sections' name is not required to match technologies anymore

  3. Common use-case to avoid repetitive definition across use-cases

  4. Sharing variables across technologies

  5. Group conditions configuration for custom/advanced configuration

# Conditions

Important

This Conditions format is deprecated and shouldn't be used. Please head over to new Conditions part.

Groups can have an attribute called condition. Groups with a condition will only be configurable through the interface when it is respected. That is particularly useful when you want to have "advanced-configurations" or specific ones based on a prior choice, e.g.: db_engine: ['mysql', 'oracle', 'pgsql', 'mongodb']

The format of this attribute is imposed and must respect the following one: <key> <operator> <value>.

  • <key> is the name of the variable that the value will be compared to. The <key> cannot belong to the same group of the condition.
  • <operator> one of the following list: ==, >, <, <=, >=
  • <value> the value you want it to compare to, can only be boolean, integer, float or string.

When configuring a project, variables belonging to the group with a condition will only be processed if that group's condition is met; otherwise, variables will simply be ignored. For more examples see the specific section.

Condition