The &
marks an alias for the node (in your example &default
aliases the development node as "default") and the *
references the aliased node with the name "default". The <<:
inserts the content of that node.
Allow me to quote the YAML spec here:
Repeated nodes (objects) are first identified by an anchor (marked with the ampersand - “&”), and are then aliased (referenced with an asterisk - “*”) thereafter.
So parts of your example
development: &default
adapter: postgresql
database: dev_development
test: &test
<<: *default
database: test_test
actually expand to
development: &default
adapter: postgresql
database: dev_development
test: &test
adapter: postgresql # from the "default" alias
database: test_test # overridden by the duplicate key
and at the same time make the "test" node as well available under the alias "test".
Have a look at the YAML specification - 2.2 Structures for further details (or if you need even moar docs++: 3.2.2.2. Anchors and Aliases)
&default
means you're labeling this set of attributes with some name for later use
<<: *default
means you're including all attributes from group labeled as default
These represent node references (*) and associative array merges (<<) that refer to a node labeled with an anchor (&) tag -- wikipedia
Try it out yourself online.
They are a way to reference environments without having to repeat the same settings over and over (DRY it up).
test: &test
<<: *default
&test
creates a reference to those specific settings.
<<: *default
says use the default settings for the test
cucumber:
<<: *test
So now we know that for cucumber
we want to use the settings from test
.
In simple words, this notion resembles with the base and derived class.
In base class template, you mention all the common details with '&', which means it can be used to expand the other yaml section that needs these fields. Now when you create another section that is superset of config values of this 'base class' type structure, you use the '*' along with the base class anchor (i.e. the one started with '&'). You use '<<:' as yaml notion for actually placing the 'base class' section, that you can override later.
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
But, if you do not want to override the extended fields, you can skip '<<:'
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With