Get certified in Microsoft Fabric—for free! For a limited time, the Microsoft Fabric Community team will be offering free DP-600 exam vouchers. Prepare now
Hello everyone,
The situation is as follows: I have a workspace with DEV with many elements and I have a UAT workspace that is Empty.
Workspace DEV
Workspace UAT
In this scenario, I only want to deploy my Warehouse item, named “Staging”, which is located here in DEV's environment.
I go to my deployment pipeline and select only “Staging” and deploy.
Deployment successfully completed
When I run a compare directly, it tells me that there are already differences between the two Staging DBs (even though I've just deployed and made no changes to DEV's Staging DB in the meantime).
Naively enough, I say to myself, let's try a new deployment to update the UAT with the DEV (even if I haven't made any changes).
and then I encounter this error
I'm confused, I don't understand...
When I go to the UAT workspace, the only strange thing I notice is that it has created the tree structure for me (Folder Staging) but has put DB Staging at the root (so the path is different from DEV's workspace)...
Since the path is different, it considers the items to be different? And this would mean a bug between deployment pipelines and folders?
While waiting for your feedback, I'll do the test with a workspace without folders.
Thank you in advance for your feedback,
Vivien
Solved! Go to Solution.
I think I figured it out ....
To deploy items in a subfolder, the folder in the destination workspace must be created by the deployment process. That way the folders are kind of connected and not "different items with the same name". If you create the subfolder in the destination workspace by hand, it is not linked to the source folder.
Once the folder is created by the deployment pipeline, the issue in this topic disappears for me.
For first time deployment of a subfolder item: if folder is already present in destination workspace: rename it and try the deployment again. Move items that are only present in the destination workspace by hand to the newly created folder.
Other issues with the deployment pipelines and folders are still there. E.g. the default semantic models and sql endpoints of deployed subfolder lakehouses that are connected to a random root level item.
I think I figured it out ....
To deploy items in a subfolder, the folder in the destination workspace must be created by the deployment process. That way the folders are kind of connected and not "different items with the same name". If you create the subfolder in the destination workspace by hand, it is not linked to the source folder.
Once the folder is created by the deployment pipeline, the issue in this topic disappears for me.
For first time deployment of a subfolder item: if folder is already present in destination workspace: rename it and try the deployment again. Move items that are only present in the destination workspace by hand to the newly created folder.
Other issues with the deployment pipelines and folders are still there. E.g. the default semantic models and sql endpoints of deployed subfolder lakehouses that are connected to a random root level item.
Hello,
Yes, it now seems to have been resolved. But before, it created the folder without putting the items in it (they were put in the root outside the folder).
Have a nice day,
Vivien
I've just done the test in a workspace in Folder, only with a DB Staging, and I don't get this error anymore.
I still have changes detected, but I can repush every time.
This seems to confirm the bug between deployment pipelines and folders (because the pipeline doesn't necessarily place the objects in the same place).
if some of you could do the test or give me some feedback that would be great 🙂
Thank in advance
Hi @vivien57
Thanks for using Fabric Community.
I tried to repro the same scenario and got the same issue. Below are the screenshots:
I have escalated this issue to our internal team. I will keep you posted regarding the updates.
Thanks
Hi @vivien57
Apologies for the issue you have been facing. The internal team has confirmed that this behaviour is happening due to a bug.
Hence I request you to create a support ticket, so that our engineering team can get a clear understanding regarding this issue.
https://support.fabric.microsoft.com/en-US/support/
After creating the ticket please provide the details here for further tracking.
Thanks
Hi @vivien57
We haven’t heard from you on the last response and was just checking back to see if you got a chance to create a support ticket. If yes please share the details here.
Thanks
Hello,
the ticket was created with this number
have a nice day,
Vivien