Views in Warehouse Breaks Source Control Sync

Hi kozman​ 

As git intergrations for Fabric Warehouses are still in Preview i think you could be encountering one of its limitations.

Cross-item dependencies between warehouses and SQL analytics endpoints aren't currently supported in development workflows. As a result, scenarios that rely on coordinated changes across these items might not work reliably.

Source: https://learn.microsoft.com/en-us/fabric/data-warehouse/git-integration

A workaround might be to follow these steps, until the limitation is no longer there.

1. Branch out to the new workspace with Select items individually checked, including only the Lakehouse (not the Warehouse)
2. Populates that Lakehouse in this environment, get its tables to exist.

3. Go back to source control and run a scoped update from git (Documentation), this should resolve the lakehouse dependency. (Should because it is still a preview item)

Hopefully this helps you.

Did I answer your question, please mark the post as a solution.

Hi kozman​,

I think you have run into a documented Warehouse CI/CD limitation rather than an issue with the view definition itself.

Microsoft's current Warehouse Git integration documentation explicitly says that cross-item dependencies between Warehouses and SQL analytics endpoints are not currently supported reliably in development workflows. It also calls out item-sequencing and synchronization gaps during branch-out and branch switching.

That matches your scenario quite closely: the Warehouse view depends on the Lakehouse SQL analytics endpoint, but in a newly created workspace that dependency might not exist yet when Fabric tries to validate/apply the Warehouse definition.

One distinction I would make around the suggested workaround is that normal Update from Git is not selective. Microsoft's Git integration process documentation states that Update always synchronizes the entire branch; you cannot choose individual items during the update.

Selective item deployment is currently available during Branch out to workspace through Selective Branching. So for a feature workspace, a possible bootstrap sequence is:

1. Branch out with only the Lakehouse selected.
2. Wait for the Lakehouse and SQL analytics endpoint to be provisioned.
3. Add the Warehouse afterward once the dependency exists.

For a CI/CD pipeline outside that branch-out flow, I would probably separate provisioning from schema deployment: create/provision the Lakehouse first, then deploy the Warehouse/view after the SQL analytics endpoint exists.

I also could not find a documented option to disable Fabric's dependency validation during Update from Git.

So I agree that this is currently awkward for Warehouse views that depend on Lakehouse SQL endpoints. Until Microsoft improves cross-item dependency sequencing/rebinding, I would treat it as a deployment-order problem and make that order explicit in the CI/CD process rather than relying on a single workspace Git sync.

Warehouse Git integration is also still documented as Preview, so I would definitely raise this as product feedback if this pattern is central to your deployment architecture.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

If we had selective sync on the normal workspace branch binding, that could allow us to provide a decent workaround to the sequencing problem (as well as solve for a bunch of other gotcha moments we've experienced with git update).  As for now, we've abandoned the idea of supporting warehouse objects in our Fabric environment until the CICD story around it is more sound.  Instead, we have pushed the views back up to being the responsibility of the consumers even though this means the views would be defined multiple times across the various consumers.  Not ideal...but this is our Plan B workaround to this problem for the moment.  I appreciate some of the insight you all have given on level of maturity on this asset and possible workarounds to consider.

I think the real CI/CD boundary is the cross-item dependency, not the view itself. SQL analytics endpoints have no version-control support today, and cross-item dependencies, sequencing, and synchronization gaps with Warehouses remain Git integration limitations. Keeping the views outside this deployment path makes sense for now.