Forum Discussion
Terraform + Azure DevOps Pipeline Issue with Fabric Notebooks
My workaround was to stop using the fabric_notebook resource to create notebooks. Instead, I treated them as templates to better handle environment-specific references. After deployment, I uploaded the notebooks manually and imported them into the Terraform state. Since there were no changes, I reactivated the fabric_notebook resource without issues.
This unblocked my code release, but I’m still working on getting it to run through the pipeline. I used a service account to perform the steps above, but my pipeline runs with a service principal. When I trigger the pipeline, it fails—saying the workspaces are already in use.
Community SupportThankyou, burakkaragoz, for your response.
Hi angela_n,
We appreciate your inquiry on the Microsoft Fabric Community Forum.
Thank you for your detailed update and for applying the key best practices, such as using depends_on, sleep, and reducing parallelism.
Please follow the steps below which may help resolve the issue:
-
Notebook deployments may fail if the dependent Lakehouses or Warehouses are not fully available, even if the workspace exists. Ensure you add explicit depends_on referencing the Lakehouse or Data resources, not only other notebooks. Also, include a check to wait until the Lakehouse API endpoint responds before proceeding.
-
Use a null_resource with local-exec to call the Fabric REST API and poll for resource readiness instead of relying only on sleep.
-
Verify that the Service Principal used by your DevOps pipeline has admin access to the Fabric workspace and has the necessary API permissions in Azure AD, such as Graph and Power BI.
-
If notebooks are created but Terraform fails to track them due to asynchronous read issues, you can manually add the resources into the state by using terraform import:
terraform import fabric_notebook.my_notebook <workspace_id>/<notebook_id> -
The error "source_content_sha256 unknown after apply" likely occurs because of how the provider handles post-creation reads. If this happens consistently, please report the issue with logs and a reproducible configuration.
Running Terraform apply locally using a service principal is a valid temporary solution to unblock production deployment.
Additionally, you may refer to the following links:
Terraform Provider for Microsoft Fabric (Generally Available) | Microsoft Fabric Blog | Microsoft Fabric
GitHub - microsoft/terraform-provider-fabric: Terraform Provider for Microsoft Fabric
Releases · microsoft/terraform-provider-fabric
Microsoft Fabric REST API references - Microsoft Fabric REST APIs | Microsoft Learn
If you find this response helpful, kindly mark it as the accepted solution and provide kudos. This will assist other community members facing similar questions.
Should you have any further queries, please feel free to contact the Microsoft Fabric community.
Thank you.
Thanks @burakkaragoz, for all your help.
Unfortunately, none of the proposed solutions have resolved the issue in my case.
I’ve tried the following:
- Creating notebooks one at a time using my own user account (which has full access and works perfectly when running tf with dev as an environment).
- Adding depends_on
- Reducing parallelism and sleep delays.
- Using terraform import after successful creation. This will recreate the object on the next execution and will delete all the objects or sometimes it return
│ Error: Resource already managed by Terraform │ │ Terraform is already managing a remote object for fabric_notebook.pitchly_load_pitchly_from_dealcloud. To import to this address you must first remove the existing object from the state. ╵Despite these efforts, the issue persists only in the new environments. What’s particularly puzzling is that the exact same Terraform configuration works flawlessly using dev. The only difference is the environment parameter (dev vs prd).
In prd, even when creating notebooks one by one, only two succeeded — the rest failed with the same error:
source_content_sha256 unknown after apply
So the issue is not related to user access or resource availability, but a Bug of the Fabric provider.My deadline is already overdue, and resorting to a manual release process will negatively impact future deployments. Sadly, this is yet another indication that Microsoft Fabric may not yet be fully ready for production.