Forum Discussion
CI/CD inconsistency for Power Bi Reports
- 1 month ago
Thak you it got fixed.
Hi ShivekMaharaj Thank you for respnding and questions. Please find the below
I'm using Fabric REST APIs (fab deploy) to achieve the deployments to UAT environment.
1. I verified that the deployed semantic model in bi-uat is connected to lakehouse in data-uat and there exists no warnings too
2. I did perform the following command to check if the report is bound to semantic model in bi-uat and yes it is connected to the right semantic model
fab api -A powerbi "groups/${{ vars.UAT_WORKSPACE_ID }}/reports" --show_headers
3. We use only a single YML file that has 2 jobs, job-1 will deploy semantic model, refreshes semantic model. Job-2 will deploy reports.
4.I'm using Managed Identity that has contributor access to both workspaces, data-uat and bi-uat.
Just to give you the current process approach. The CI (build) is, will upload the code as artifact. The CD (deploy) is, will download the artifact, replace the workspace id and lakehouse id of dev with UAT ids and deploy
I'm not able to identify which is causing this issue, but I believe there is something thatbis causing this issue.
Appreciate your help if there is anything I could check to fix this issue.
- ShivekMaharaj1 month ago
Memorable Member
Hi mohan072,
Thanks, that helps. If the semantic model in bi-uat is definitely connected to the Lakehouse in data-uat, and the report is also bound to the correct UAT semantic model, then I would stop looking at binding for now.
The next thing I would isolate is whether the semantic model itself is healthy after deployment.
Since you are using the REST APIs, one thing worth checking is the refresh sequencing. A semantic model refresh request is asynchronous, so the API call succeeding does not necessarily mean the refresh has finished successfully. Microsoft documents this under enhanced refresh with the Power BI REST API.
I would make sure Job 2 does not deploy the reports until the UAT semantic model refresh status has actually reached Completed, rather than just continuing after the refresh request was accepted.
I would also try a very simple DAX query directly against the UAT semantic model using the Execute Queries REST API.
Something as simple as:
EVALUATE TOPN(10, 'YourTable')If that fails, then the report is probably only exposing a semantic model/data-access problem underneath it.
If the DAX query succeeds but the report visuals still fail, then I would compare the deployed report definition with Dev next, because at that point the model, Lakehouse connection and data path have all been proven independently.
One other thing I would check if this is Direct Lake is the identity being used when the model queries the Lakehouse. Microsoft notes that Direct Lake access can depend on either the report user having ReadData on the Lakehouse or the semantic model using a fixed identity with access to the source. Simply giving the CI/CD identity Contributor access does not necessarily prove that the runtime query identity has access. The Fabric permission model.
So my next three checks would be:
- Confirm the semantic model refresh actually reaches Completed.
- Execute a simple DAX query directly against the UAT semantic model.
- If it is Direct Lake, verify the runtime identity/connection has access to the UAT Lakehouse.
That should tell us whether the failure is still in the semantic model layer or genuinely only in the deployed report.AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
- mohan0721 month agoRegular Visitor
Thak you it got fixed.
- v-aatheeque1 month ago
Community Support
Hi mohan072
Thanks for confirming! Glad to hear the issue is fixed. It looks like the issue was related to insufficient permissions for the user. Appreciate you confirming the resolution.