Anchors, Aliases, Tags

Anchors (&name): mark a node for reference. Aliases (*name): reference an anchored node.

default_config: &defaults
  timeout: 30
  retries: 3

dev:
  <<: *defaults
  host: dev.example.com

prod:
  <<: *defaults
  host: prod.example.com

Result:

dev: {timeout: 30, retries: 3, host: 'dev.example.com'}
prod: {timeout: 30, retries: 3, host: 'prod.example.com'}

<<: *anchor: merge keys from anchor into current map. Local keys override.

Aliases share THE SAME node:

shared: &shared {value: 42}
ref1: *shared
ref2: *shared

ref1 and ref2 point to the same map. If parser preserves identity: modifying one modifies all.

Recursive anchors:

node: &node
  child: *node

Most parsers detect cycles and either reject or limit depth.

Tags (!tag): explicitly type a node.

explicit_string: !!str 42
explicit_int: !!int "42"
custom: !mytype value

!! prefix: standard YAML schema tags (str, int, float, bool, null, seq, map, binary, set, omap, ...).

! prefix: app-specific.

date: !!date 2024-05-13
secret: !vault |
  encrypted_data_here

Apps register tag handlers. Unknown tags: usually preserved as opaque or rejected.

Use cases:

• K8s YAML: kind: Deployment is a normal string, but the resource type drives parsing.
• Helm templates: tags help template engine.
• Ansible: many custom types.

Most YAML you read doesn't use anchors/tags. They're advanced features.

When to use:

• Anchors: avoid duplication (DRY).
• Tags: explicit type or custom semantics.

When to avoid:

• Casual configs (overkill).
• Files edited by non-YAML people (confusing).

GitHub Actions doesn't support anchors. Many CI tools have limits.