[FEATURE] Option to supply parameter Python dictionary instead of YAML

[TarekSalha]

What is the feature?

Summary

Add support for passing find_replace parameters dynamically as a Python dictionary to FabricWorkspace instead of requiring a YAML file.

Current Behavior

Currently, fabric-cicd requires parameters to be defined in a parameter.yml file in the repository directory. The tool reads this file during deployment to apply find/replace transformations.

Example current workflow:

# Must write to file first
parameter_config = {
    'find_replace': [
        {'find': 'OLD_VALUE', 'replace': 'NEW_VALUE'}
    ]
}
with open('Reports/parameter.yml', 'w') as f:
    yaml.dump(parameter_config, f)

# Then deploy
workspace = FabricWorkspace(
    workspace_id=workspace_id,
    repository_directory='Reports',
    item_type_in_scope=['SemanticModel', 'Report'],
    credential=credential
)
publish_all_items(workspace)

Desired Enhancement

Allow passing parameters directly as a dictionary to FabricWorkspace or publish_all_items(), eliminating the need to write temporary YAML files.

Proposed API

Option 1: Pass to FabricWorkspace constructor

workspace = FabricWorkspace(
    workspace_id=workspace_id,
    repository_directory='Reports',
    item_type_in_scope=['SemanticModel', 'Report'],
    credential=credential,
    parameters={
        'find_replace': [
            {'find': 'OLD_SERVER', 'replace': 'new-server.com'},
            {'find': 'OLD_DB', 'replace': 'new_database'}
        ]
    }
)

Option 2: Pass to publish_all_items()

publish_all_items(
    workspace,
    parameters={
        'find_replace': [
            {'find': 'OLD_SERVER', 'replace': 'new-server.com'},
            {'find': 'OLD_DB', 'replace': 'new_database'}
        ]
    }
)

Option 3: Both (with parameter precedence)

• If parameters are passed via constructor/function, use those
• Otherwise, fall back to reading parameter.yml file (backward compatible)

Use Cases

1. Dynamic CI/CD Pipelines

In automated deployment pipelines, parameters often come from:

• Environment variables
• Pipeline variables
• Secrets management systems
• Runtime configuration

Writing these to a file adds unnecessary I/O and complexity.

2. Multi-Tenant Deployments

When deploying to multiple workspaces with different configurations:

for tenant in tenants:
    parameters = {
        'find_replace': [
            {'find': 'TEMPLATE_NAME', 'replace': f'Tenant_{tenant.id}'},
            {'find': 'TEMPLATE_SERVER', 'replace': tenant.server_endpoint}
        ]
    }
    workspace = FabricWorkspace(..., parameters=parameters)
    publish_all_items(workspace)

3. Runtime-Fetched Values

When parameters depend on runtime-fetched resources:

# Fetch lakehouse endpoint at runtime
lakehouse = fabric_client.get_lakehouse(workspace_id, lakehouse_name)
sql_endpoint = lakehouse.properties['sqlEndpointProperties']['connectionString']

# Use directly without file I/O
parameters = {
    'find_replace': [
        {'find': 'HARDCODED_ENDPOINT', 'replace': sql_endpoint}
    ]
}
workspace = FabricWorkspace(..., parameters=parameters)

Benefits

1. Simplified Code: Eliminates need to write/delete temporary YAML files
2. Better Performance: Avoids file system I/O operations
3. Cleaner CI/CD: No intermediate files to manage or clean up
4. More Pythonic: Follows Python idioms for configuration
5. Backward Compatible: Can still support YAML files for static configurations
6. Reduced Dependencies: No need to import yaml in user code for dynamic scenarios

Additional context

No response

[shirasassoon]

@TarekSalha Thanks for the feature idea and details! We will keep this on the backlog to implement in future releases.