git sync order error on warehouse declare in workspace with dependencies

[echaintreau]

Hello all,

I am encountering a challenge in the git synchronisation of workspace on Fabric when there is 2 warehouses define in them with dependencies. Notably during the git sync.

Some context first, we use git to work on different workspace on Fabric. Those workspace are deploy using the git sync. Each developper as its own branch and retrieve and push change to a define reference branch (name main).

On those workspace we have different items defined that are store in git data pipeline to upload data, notebooks for analysis, ... and among them 2 warehouses (name SWarehouse and PWarehouse). In the design the PWarehouse use some table/view from SWarehouse in its definition like `CREATE VIEW ... FROM SWarehouse.aaaa`

Now the problem: When git realise the sync to another environment, it seems to do it in alphabetic order so in our case the PWarehouse is syncing first. When the sync happens it failed sometime cause an information in SWarehouse has not been sync yet. For exemple SWarehouse.aaaa do not exist or if column xxxx in table SWarehouse.aaaa not found. This make the all sync crash even if those table are still defined in the same commit.

My question then is: 

- is there a way in Fabric, in git or in the warehouse definition to manage those dependencies ? like a deploy SQL Project would

- or also is there a way to deactivate those checking on the Warehouse, to force the update (that can be fix later on) ?

Luckily in my example I can also fix my issue by simply renaming my Warehouse like (1_SWarehouse, 2_PWarehouse) and it would work as I do not have dependencies from Swarehouse to Pwarehouse. But this imply to redo connection and shortcut present on both warehouse so not a simple task to do. Also in case of multi-dependency this would not work.

Would anyone have an idea about it ?

Thanks in advance

[KevinChant]

Thinking outside of the box here, do you have other fabric items in that workspace? If not, it might be a good idea to orchestrate the deployment of the Warehouses with a database projects instead to get control of the ordering and any post-deployment tasks.

[echaintreau]

Well Update from my part.

It seems that renaming the Warehouse is not the solution, I try renaming my SWarehouse in 1_SWarehouse and my GWarehouse in 2_GWarehouse but it did not fix the issue. It seems that git sync do not respect an order at all and try to update everything at once.

This mean that the order is quite random in the end where the file that are update the first (those define with the less total line) seem to be the one that are the first to sync. in the nend the only solution I found is to do the sync manually by removing the items that need to be done last and re-upload them afterward in our git. But this can clearly not be automated.

Here a good introduction on the subject: Microsoft Fabric Pipeline Deployment Order: A Painful Workaround and a Call for a Real Fix

I also try the pipeline using the Fabric-CICD library but the deployment create new element instead of replacing them and it break the sync afterward cause git sync want to remove those items to recreate them.

Is there any solution at all in the end ?

I also push people to add to the open feature idea : Enable Configurable Deployment Order for Initial S... - Microsoft Fabric Community

Thanks in advance

[echaintreau · Accepted solution]

Final Update from our side

We did found a solution but it implies some works to be done.

In the end what we did was to implement a Mini-deployment pipeline on Azure Devops, that force some change on the SWarehouse for the GWarehouse update to work. 

We use notably use fabric-cicd to deploy change on items themself and for the SWarehouse, we use SQLPackage logic to deploy SWarehouse from another Workspace that was use as reference. ANd for our use case we could not deploy directly the Warehouse we need to custom the SQL script generated by SQLPackages cause some functionnality where not available in the Fabric Warehouses. After the pipeline run sucessfully you only need to relaunch the git Sync and override manually all conflict that rise on Warehouses.

It is however not a ideal solution as it is really time consuming cause you need to launch a sync, check that the pb is comming from the SWarehouse, lauch the pipeline to re-sync everything and re-sync again from git on the workspace. That can take up to 30 mins in total on our case and also you need to stay on the Workspace page when you do a git update cause it rise Warehouse warning on data loss. If you miss those popup the sync will failed. and you need to re-do it again.

Really hope some improvment will be done ny Microsoft on those Warehouse update from git in the near future.

Thanks all

[v-ssriganesh]

Hello @echaintreau,
Thank you for sharing these detailed findings and you’ve done excellent due diligence testing all available options.

Currently, there is no fully supported, automated solution in Fabric Git sync that:

• Guarantees deployment order for interdependent warehouses,
• Avoids creating new objects (as in pipelines),
• And keeps Git sync in a clean state.

Renaming, splitting sync steps manually, or maintaining separate deployment workspaces are currently the only reliable workarounds. Unfortunately, there is no configuration to disable dependency checks or enforce deterministic ordering during Git sync.

Thanks for sharing the idea link. if the idea receives more upvotes, the Microsoft product team will review it and consider implementing it in the future. To help it get more visibility, please “Accept as Solution” and consider giving a “Kudos” to assist other community members in resolving similar issues more efficiently.

Thank you.

[v-ssriganesh]

Hello @echaintreau,

As haven’t heard back from you in a long while, we’re closing this thread per our follow-up policy. For any further discussions or questions, please start a new post in the Microsoft Fabric Community Forum — we’ll be happy to assist.

Thank you for being part of the Microsoft Fabric Community.

[echaintreau]

@burakkaragoz Thank you for your quick answer. I unfortunately expect such answer. In my case think the renaming is the best option here.  I though about the pipeline deployment but I can not do that on dev workspace where user can have some works and take the risk to erase there work.  

Kudo left and I would not miss to upvote the feature request. For the last entry not sure it would work cause in a try catch the system will not failed but the view will also not exist so in that case I would need to redo a sync or re launch the script that I can not do.

[burakkaragoz]

Hi @echaintreau ,

Yeah, this is a known limitation with Git sync in Fabric right now — it doesn’t handle object-level dependencies like SQL Projects do. It just deploys items in alphabetical order, which can break things when one Warehouse depends on another.

Here’s a few practical options:

1. Prefixing names like you did (1_SWarehouse, 2_PWarehouse) is the most reliable workaround for now. I know it’s annoying with shortcuts and connections, but it guarantees the right order.
2. If you’re using pipelines for deployment, you can split the sync into two steps: sync SWarehouse first, then PWarehouse. This gives you full control over the order.
3. There’s no current setting to disable dependency checks during sync, but you can try wrapping your dependent views in TRY_CAST or TRY_SELECT logic to avoid hard failures — not ideal, but it can help in some cases.

Also, you might want to upvote this feature request or raise it via Fabric Ideas:
👉 https://aka.ms/fabricideas

Let me know if you want help setting up a two-step pipeline or automating the sync order.

If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.

Translation and formatting supported by AI