$allez.* variables¶

These tokens extend fabric-cicd's parameter.yml replacement rules.

A $allez.* token names a workspace this repo owns, or an item in it, from inside a parameter.yml rule; you need one when a rule must reach another sub-folder's workspace and follow --env and the branch. fabric-cicd's own dynamic variables reach another workspace only by a literal display name (Which mechanism for a cross-env reference), and a literal name can follow neither --env nor a branch.

allez's tokens key on the sub-folder instead, and read the answer from that folder's own config.yml, so one rule serves every environment. They use the same grammar as fabric-cicd, behind a namespace: $ marks keywords, bare segments are names you chose.

find_replace:
  - find_value: 'onelake\.dfs\.fabric\.microsoft\.com/([0-9a-fA-F-]{36})/'
    is_regex: "true"
    replace_value:
      _ALL_: "$allez.data.$workspace.$id"

Some references take a workspace name. Spark SQL's four-part name for a table in another workspace is one: `<workspace>`.<lakehouse>.<schema>.<table> (cross-workspace Spark SQL queries). The $name form fills it in:

find_replace:
  - find_value: 'FROM `[^`]+`\.Sales\.dbo\.orders'
    is_regex: "true"
    replace_value:
      _ALL_: "FROM `$allez.data.$workspace.$name`.Sales.dbo.orders"

Keep the backticks: a branch workspace's name has [ and ] in it. Use the $id form in any OneLake or abfss:// URL. OneLake's ABFS driver refuses special characters in a workspace name, so a name-based path breaks on every feature branch.

Some references take a SQL endpoint: a Direct Lake-on-SQL model's Sql.Database(<host>, <database>) in expressions.tmdl, a dbt profile's endPoint, any TDS connection string. The $sqlendpoint form fills it in:

find_replace:
  - find_value: 'Sql\.Database\("([^"]+)"'
    is_regex: "true"
    replace_value:
      _ALL_: "$allez.data.$items.Warehouse.Sales.$sqlendpoint"
    item_type: "SemanticModel"
    file_path: "/Sales.SemanticModel/definition/expressions.tmdl"

An attribute the item type does not have ($sqlendpointid on a warehouse, either on a notebook) fails at load, before any Fabric call, naming the types that have it. A lakehouse whose SQL endpoint is still provisioning fails the node and says to run again; the endpoint usually follows the item within a minute, and the pipeline is safe to re-queue.

To fabric-cicd a token is plain text: allez deploy resolves each one to a real id immediately before that node's fab deploy, then restores parameter.yml, so the repo keeps its tokens and one run's ids never carry over into the next. Resolution is a literal text substitution, all or nothing: nothing is written unless every token resolves. A token that matches none of the forms is a load-time error that lists them all. Comments survive, and a token resolves in an extend template just as in the main file.

A workspace id resolves whether or not the workspace holds anything. An item id needs that item to be published already; the dag is what guarantees an earlier node has published it.

A node resolves only the rules for the item types it publishes. A rule says which items it is for with item_type, or with the item folder in file_path; a node's types are its core.item_types_in_scope, with its overlay merged. A token that only rules for other types carry is left as written and printed as deferred under parameters; the node that publishes those types resolves it. That is how a workspace the dag visits twice can name an item a later node publishes: the sample's pipeline, in allez-orchestration, names allez-data's notebook and allez-reporting's model, and its rules all carry item_type: DataPipeline, so the first visit (the SQL database) defers them and the overlay that publishes the pipeline, last in the dag, resolves them (Overlays). A rule with neither filter is resolved on every visit.

A live run looks every token up in Fabric and never reads the .allez/cache/ folder; --plan does (Commands).