Github integration and Semantic Model Parameters

[HankoSwart]

We moved away from Power BI deployment pipelines and are now using the GitHub integration for versioning and deploying from one workspace to the other (Development to Test to Prod)

One thing we now struggle with is updating parameters across workspaces.

In Development, we don't want all the historic data, 2 years max. Test and Production are set with different values. Yet, when we now use GitHub, parameters are also overwritten (expressions.tmdl). It's also not possible to add this to .gitignore as there are other helper functions that might also be a part of this tmdl file and needs to sync.

We tried with custom actions in Github, but upon commit after successfully changing the parameters, there is a divergence in GitHub that always result in conflicts when merging branches at a laters stage.

Using the REST API also turns out to be quite a struggle as the Service Principle cannot update parameters, only the dataset owner (which might be a different account - in our case it is)

Does anyone have experience with this? Maybe someone can give us some pointers on how to approach this?

[rajendraongole1 · Accepted solution]

Hi @HankoSwart - One effective method is to separate configuration files for each environment (Development, Test, Prod) within your repository. For example, you could maintain environment-specific parameter files (e.g., parameters.dev.json, parameters.test.json, parameters.prod.json) that contain only the required parameter settings for each workspace.
Automate Parameter Injection: Use GitHub Actions or a deployment script that reads the appropriate parameter file based on the target environment and injects the parameters directly into the deployment process. By injecting these parameters only at deployment, you can avoid altering the expressions.tmdl in the source branch, reducing the risk of merge conflicts.

OR

Power BI REST API

If possible, consider temporarily assigning dataset ownership to the service principal for deployment purposes. You can automate this using PowerShell or the REST API, where the service principal takes ownership, updates parameters, and then reassigns ownership back to the original user.
Update Parameters on Deployment: Once the service principal has ownership, it can update dataset parameters through the REST API for each environment after deployment. This would allow you to handle parameter changes without directly modifying the source files in GitHub.