Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 

Be one of the first to start using Fabric Databases. View on-demand sessions with database experts and the Microsoft product team to learn just how easy it is to get started. Watch now

Reply
vivien57
Helper V
Helper V

Issue - Deployment pipeline and folders don't work together?

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

vivien57_0-1717491784292.png


Workspace UAT 

vivien57_1-1717491784299.png

 

In this scenario, I only want to deploy my Warehouse item, named “Staging”, which is located here in DEV's environment.


vivien57_2-1717491831639.png

 

I go to my deployment pipeline and select only “Staging” and deploy.

 

vivien57_3-1717491886092.png

 

vivien57_4-1717491904063.png

Deployment successfully completed

 

vivien57_5-1717491933959.png

 

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).

 

vivien57_6-1717491972119.png


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).

 

vivien57_7-1717492029288.png

 

and then I encounter this error

 

vivien57_8-1717492049537.png

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)...

 

vivien57_9-1717492088618.png

 

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

1 ACCEPTED SOLUTION
arjaano
Advocate I
Advocate I

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.

View solution in original post

7 REPLIES 7
arjaano
Advocate I
Advocate I

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

vivien57
Helper V
Helper V

I've just done the test in a workspace in Folder, only with a DB Staging, and I don't get this error anymore.

vivien57_0-1717493934499.png

 




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:

 

vnikhilanmsft_1-1717498670543.png


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

vivien57_0-1717999213491.png

have a nice day,

Vivien

 

Helpful resources

Announcements
Las Vegas 2025

Join us at the Microsoft Fabric Community Conference

March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount!

Dec Fabric Community Survey

We want your feedback!

Your insights matter. That’s why we created a quick survey to learn about your experience finding answers to technical questions.

ArunFabCon

Microsoft Fabric Community Conference 2025

Arun Ulag shares exciting details about the Microsoft Fabric Conference 2025, which will be held in Las Vegas, NV.

December 2024

A Year in Review - December 2024

Find out what content was popular in the Fabric community during 2024.