Forum Discussion
Git Branch no syncing to new workspace
Hello,
My apologies if this is a little long winded, but I'm uncertain what details will be important. I am trying to set up a git integration to use as version control. Our goal is to set up a PR system instead of having developers write directly on the production workspace.
I can integrate the production workspace with git just fine. When I create a branch though, a new workspace will fail to sync with said branch. I have tried multiple times with the same result. What usually happens is I get a generic failure message, "Unable to complete update request'. After that I usually end up with a 'SQL endpoint name already exists' or something along those lines. If I wait long enough, the second type of error doesn't occur, but I return to the first. Now I get 180-200 (out of around 250) items to appear in the new workspace that appear to be in a partial sync status (they appear in changes, but the status is 'You need to update the workspace to the lastest commit'). The number of items does not change with each subsequest attempt, but the cycle continues: generic error then some duplicate naming error. I have tried removing the offending files in an attempt to get some things to sync, but it usually just means another error occurs.
Any idea what is going on or how to get around it?
Hello LucasKramer, based on how you explain your goal to "set up a PR-based system" instead of making changes directly in the production workspace, below is my suggestion. A quick disclaimer: I won't be explaining the error messages you get, as the approach I suggestis different.
1. The workspace structure: you need a separate workspace for each of your environment: Dev, Test, Prod. Don't name them manually, come up with a uniformed naming convention, as in ws_solution1_dev, ws_solution1_test, etc.
2. Only connect the Dev workspace to a Git account and only to a main branch. Other workspaces should be deployed to from the same source of truth - that is a single main (or other name) branch in Git. Make sure that your main branch is protected from direct pushes and can only be updated via a PR merge.3. To implement PR-based process, all changes must be made in a Feature-specific workspace, not in any of the environment workspaces. You need to enforce a discipline and not allow your developers/engineers make direct changes in any of the shared environment workspaces (permissions).
4. In practice, this means the following Development Life Cycle (DLC):
Git main -> Dev workspace -> Feature workspace -> merge into main -> update Dev workspace.
5. In addition, you need a Release Cycle:
Dev workspace -> deployment -> Test workspace -> deployment -> Prod workspace.6. You have two way of implementing DLC:
Manual:a. branch out from Dev workspace into a Feature workspace that will create a new branch from main and connect to a Feature workspace.
b. Finish development and testing in Feature workspace, then merge feature branch into main branch via PR and update your Dev workspace voa Git integration from main. Run tests in the Dev workspace.
c. Use development pipeline and deploy to Test workspace from Dev workspace; run tests.
d. Deploy from Test workspace to Prod.
Automated:
Replace a) from the manual process with a Git automation that creates a new branch from main, creates a new Feature workspace in Fabric using API, populates Feature workspace from Feature Git branch. Then continue as above.
This is a proven approach but here I can only explain so much. So this is a sketch and there are always nuances in every organization. But I hope you get an idea. The errors you mentioned above are results of how you make and synchronize changes between Fabric and Git: it can get very messy, so instead of fighting those errors, use a clean straightforward one-way sync as I suggested above that will avoid such errors.
If you find this helpful consider giving kudos and mark as a solution.
4 Replies
Olá, boa tarde!
Parece mais uma limitação/conflito do Fabric Git Integration no branch out do que um problema do repositório em si.Pelos sintomas que você descreveu, eu investigaria principalmente três pontos:
- conflito de logicalId ou de display name + type durante o Update from Git;
- conflito em itens que criam SQL analytics endpoint automaticamente, como lakehouses/warehouses;
- artefatos que usam workspace identity, porque a Microsoft informa que esses itens só atualizam corretamente para um workspace conectado à mesma identity, e isso também afeta branch out.
O fato de o novo workspace ficar com vários itens em estado parcialmente sincronizado também bate com o comportamento documentado de falha parcial no Update from Git: alguns itens entram, um falha, e o workspace fica preso nesse estado até a inconsistência ser resolvida.
O que eu testaria na prática:
- criar um workspace novo e totalmente vazio para o branch;
- usar branch-out seletivo com poucos itens para identificar qual item dispara a falha;
- revisar se existe item duplicado por nome/tipo ou conflito de logicalId;
- verificar especialmente lakehouses/warehouses e seus SQL endpoints;
- se houver uso de workspace identity, recriar/configurar isso manualmente no workspace de destino em vez de confiar só no sync;
- considerar dividir esse workspace em partes menores, porque a própria Microsoft recomenda isso quando há centenas de itens.
Se o objetivo final é promover mudanças com mais segurança, eu tenderia a usar workspaces isolados por dev/feature branch e deployment pipelines para dev/test/prod, em vez de depender do workspace de produção como base do fluxo.
Hello LucasKramer, based on how you explain your goal to "set up a PR-based system" instead of making changes directly in the production workspace, below is my suggestion. A quick disclaimer: I won't be explaining the error messages you get, as the approach I suggestis different.
1. The workspace structure: you need a separate workspace for each of your environment: Dev, Test, Prod. Don't name them manually, come up with a uniformed naming convention, as in ws_solution1_dev, ws_solution1_test, etc.
2. Only connect the Dev workspace to a Git account and only to a main branch. Other workspaces should be deployed to from the same source of truth - that is a single main (or other name) branch in Git. Make sure that your main branch is protected from direct pushes and can only be updated via a PR merge.3. To implement PR-based process, all changes must be made in a Feature-specific workspace, not in any of the environment workspaces. You need to enforce a discipline and not allow your developers/engineers make direct changes in any of the shared environment workspaces (permissions).
4. In practice, this means the following Development Life Cycle (DLC):
Git main -> Dev workspace -> Feature workspace -> merge into main -> update Dev workspace.
5. In addition, you need a Release Cycle:
Dev workspace -> deployment -> Test workspace -> deployment -> Prod workspace.6. You have two way of implementing DLC:
Manual:a. branch out from Dev workspace into a Feature workspace that will create a new branch from main and connect to a Feature workspace.
b. Finish development and testing in Feature workspace, then merge feature branch into main branch via PR and update your Dev workspace voa Git integration from main. Run tests in the Dev workspace.
c. Use development pipeline and deploy to Test workspace from Dev workspace; run tests.
d. Deploy from Test workspace to Prod.
Automated:
Replace a) from the manual process with a Git automation that creates a new branch from main, creates a new Feature workspace in Fabric using API, populates Feature workspace from Feature Git branch. Then continue as above.
This is a proven approach but here I can only explain so much. So this is a sketch and there are always nuances in every organization. But I hope you get an idea. The errors you mentioned above are results of how you make and synchronize changes between Fabric and Git: it can get very messy, so instead of fighting those errors, use a clean straightforward one-way sync as I suggested above that will avoid such errors.
If you find this helpful consider giving kudos and mark as a solution.
Below two step process help you on your scenario.
1. Create pre stage workspace for deployment and use deployment pipeline for other environment.
2. Connect with Github for code repository and sync up with pre stage workspace.
- Development Phase
Developers create and modify Fabric artifacts in:
ws_<function>_data_dev- This workspace is used purely for development and experimentation
- No direct Git sync from this workspace
- Promotion to Deployment Workspace (Pre-Git Stage)
- Only validated, sprint-ready artifacts are moved from:
ws_pricing_data_dev → ws_<function>_data_deployment - This acts as a controlled staging workspace before Git integration
- Movement can be manual or via internal promotion standards
- Git Integration (Deployment Workspace Only)
- ws_<function>_data_deployment is connected to Git
- From this workspace:
- Create feature branch
- Commit Fabric artifacts
- Push changes to repository
- Ensures only approved and stable content is version-controlled
- Pull Request (PR) & Code Review
- Raise PR from feature branch → main
- Perform:
- Code review
- Design validation
- Dependency checks
- Merge to Main Branch
- Approved PR is merged into main
- main represents deployment-ready baseline
- UAT Deployment Phase
- Use Fabric Deployment Pipelines to deploy from:
Deployment → UAT workspace
- Use Fabric Deployment Pipelines to deploy from:
- Perform:
- Functional testing
- Data validation
- Production Deployment Phase
- Promote from UAT → Production via Fabric Deployment Pipelines
- Apply:
- Environment-specific configurations
- Secrets / connections
- Development Phase
Hi LucasKramer,
Have you had a chance to review the solution we shared by AndersonLopesOl apturlov BalajiL? If the issue persists, feel free to reply so we can help further.
Thank you.
