Que signifient les &, <<, * dans ce fichier database.yml?

Jusqu'à présent, je n'ai utilisé que database.yml avec chaque paramètre appelé explicitement, dans le fichier ci-dessous, il utilise des caractères que je ne comprends pas. Que signifient chaque ligne et symbole (&, *, <<), comment lire ce fichier?

development: &default
  adapter: postgresql
  database: dev_development

test: &test
  <<: *default
  database: test_test


cucumber:
  <<: *test

production:
  <<: *default
  database: test_production

Le &marque un alias pour le nœud (dans votre exemple, &defaultalias le nœud de développement comme "par défaut") et les *références au nœud avec le nom "par défaut". Le <<:insère le contenu de ce nœud.

Permettez-moi de citer la spécification YAML ici:

Les nœuds répétés (objets) sont d'abord identifiés par une ancre (marquée d'une esperluette - «&»), puis sont ensuite aliasés (référencés par un astérisque - «*») par la suite.

Donc des parties de votre exemple

development: &default
  adapter: postgresql
  database: dev_development

test: &test
  <<: *default
  database: test_test

étendre réellement à

development: &default
  adapter: postgresql
  database: dev_development

test: &test
  adapter: postgresql       # from the "default" alias
  database: test_test       # overridden by the duplicate key

et en même temps rendre le nœud "test" également disponible sous l'alias "test".

Jetez un œil à la spécification YAML - 2.2 Structures pour plus de détails (ou si vous avez besoin même de la documentation moar ++: 3.2.2.2. Anchors and Aliases )

&default signifie que vous étiquetez cet ensemble d'attributs avec un nom pour une utilisation ultérieure

<<: *default signifie que vous incluez tous les attributs du groupe étiqueté par défaut

Ceux-ci représentent des références de nœuds (*) et des fusions de tableaux associatifs (<<) qui font référence à un nœud étiqueté avec une balise d'ancrage (&) - Wikipédia

Essayez-le vous-même en ligne .

Ils sont un moyen de référencer des environnements sans avoir à répéter les mêmes paramètres encore et encore (SÉCHER).

test: &test
  <<: *default

&test crée une référence à ces paramètres spécifiques.

<<: *default dit utiliser les paramètres par défaut pour le test

cucumber:
  <<: *test

Alors maintenant, nous savons que cucumbernous voulons utiliser les paramètres de test.

En termes simples, cette notion ressemble à la classe de base et dérivée.

Dans le modèle de classe de base, vous mentionnez tous les détails communs avec '&', ce qui signifie qu'il peut être utilisé pour développer l'autre section yaml qui a besoin de ces champs. Maintenant, lorsque vous créez une autre section qui est un sur-ensemble de valeurs de configuration de cette structure de type «classe de base», vous utilisez le «*» avec l'ancre de la classe de base (c'est-à-dire celle qui commence par «&»). Vous utilisez «<<:» comme notion yaml pour placer réellement la section «classe de base», que vous pouvez remplacer plus tard.

vsm:
  stub_nsx_mgr: &MGR_CTRL_STUB
    username: ADMIN
    password: $DEFAULT_PASSWORD
    deployment: ovf
    build: $PR_BUILD
    vmnics:
      - network: $MANAGEMENT_NETWORK_0
    vc: vc_0
    ovf_options:
      - --diskMode=$DISKMODE
      - --deploymentOption=$DEPLOYMENT_OPTION
$MGR_0:
    <<: *MGR_CTRL_STUB
    ovf_path_regex: 'appliance.*\.ovf'
    ovf_options:
      - --diskMode=$DISKMODE
      - --deploymentOption=$DEPLOYMENT_OPTION
$CTRL_0:
    <<: *MGR_CTRL_STUB
    ovf_options:
      - --diskMode=$DISKMODE
      - --allowExtraConfig
$CTRL_1:
    *MGR_CTRL_STUB

Mais, si vous ne souhaitez pas remplacer les champs étendus, vous pouvez ignorer «<<:»