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

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

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
September Hackathon Carousel

Microsoft Fabric & AI Learning Hackathon

Learn from experts, get hands-on experience, and win awesome prizes.

October NL Carousel

Fabric Community Update - October 2024

Find out what's new and trending in the Fabric Community.