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
File level commit - Need the ability to edit the commit description
I tried the recently announce file level commit for Fabric items. One notable issue I have with the feature (testing this with a Fabric warehouse, I'm assuming this would hold true for other items): ...DataBard1 hour agoMost Valuable ProfessionalNew36Views0likes3CommentsNot found value "Available gateway clusters"
Hi, Currently the machine (A) hosting power BI on-prime gateway standard. Machine (B) also want to host this server with machine (A). Gateway on (A) and (B) is using the same tenant as admin user. I...Thas_Michael22 hours agoHelper INew9Views1like0CommentsFabric Deployment Pipeline Should Automatically Preserve or Upgrade Semantic Model Compatibility
Category: Microsoft Fabric — Deployment Pipelines | Semantic Models | Direct Lake The Problem When deploying a Direct Lake semantic model containing calculated columns or calculated tables throug...Murtaza_Ghafoor23 hours agoSuper UserNew4Views0likes0Comments