Currently the .gitignore file is, well, ignored. Ideally we would have a way of using gitignore to avoid committing local developer objects e.g. sandbox lakehouses that developers use for testing out different load patterns.
9 Comments
- DanielSDavisFrequent VisitorThis is so critical. We have things all the time that we want to keep in one workspace that isn't part of the push to github. Also it'd be useful to use so we can turn OFF behavior. .schedule files come to mind. I don't my nightly loads in Production running every night in development branches, but if I delete the schedule it just recreates it.
- YevgenyM
Advocate IV
Agree. really needed. To avoid committing local developer objects - RobSewellRegular VisitorThis is really important to ensure that seasoned developers do not make mistakes and think that the .gitignore file will stop their scratch pads, notes, test files, or worse case secrets being synced to the remote repository
- Stolt_DataNew MemberThis is source control 101
- merrillaldrichNew MemberAbsolutely required!
- rabinjais7Regular Visitorthis is must. i want to keep my ms fabric git source control tab without any red marks. it makes confusing for new developers. i just want a space in workspace where people can create their notebooks, pipeline and do their work untill its finished and these should not be tracked in git ui and it should not be committed too.
- CraigRGNew MemberFabric git is clunky enough. How do you not respect .gitignore? seems pretty simple.
- DanielSDavisFrequent VisitorCraigRG, Nailed it. .schedules was the biggest thing we ran into lately, by .py files are a nightmare too. With schedules if you create your schedules in a lower branch as "inactive" when you git-push to higher branches they are still inactive. If you change their status in higher branches (like production) they register as changes and affect future pulls to your lower branches. Add to that the fact that we (like most seasoned developers) have protected branches, when our production branch adds a .schedules file that isn't in the repo it flags the workspace as in an unsynced state, which we can't push back to github. We implemented a workaround by using a yaml file for the schedules and dynamically building the .schedule file as part of our PR process (github actions). Even that was a pain because when it lands in Fabric, they take the ingestion then rebuild the file. CRLF endings in JSON were different than in github so it was changing the files. The same thing happens with Notebooks. The are converted to and from a .py file into a .ipynb file and stored as a base64 string, so every single time you try to sync your branch character interpolation happens. You have to become an expert in character encoding, github action scripts, and the Fabric API to work around all the nuance. Just insane.
- yaronprigal
Microsoft Employee
Hi all, thanks for your valuable feedback, we are starting review this idea.
Recent ideas
Native Git Integration in Power BI Desktop using PowerShell (Developer Mode for PBIP projects)
With the introduction of the PBIP (Power BI Project) format, Power BI has taken a huge step toward modern development workflows, including proper version control and CI/CD practices. However, today ...matheusmg_201 hour agoNew MemberNew538Views2likes1CommentAuto-generate INSERT VALUES scripts for configuration data migration across environments
Hi Fabric Team, I would like to suggest a feature that could significantly simplify deployment and environment promotion activities. Today, when configuration tables contain reference or applicatio...todigen4 hours agoRegular VisitorNew11Views1like0CommentsAllow Non-Breaking Schema Changes in Fabric CI/CD Deployments for Data Warehouse Objects
Hi, currently, Microsoft Fabric deployment pipelines can fail when a Data Warehouse deployment contains schema changes such as adding, removing, renaming, or modifying columns in existing tables. I...todigen4 hours agoRegular VisitorNew9Views0likes0Comments