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
Accessibility issue in the Share dialog of embedded Power BI reports
Accessibility issue in the Share dialog of embedded Power BI reports I would like to share an accessibility finding identified while testing an embedded Power BI report published as part of the cont...ugartema9 minutes agoAdvocate INew46Views7likes1Comment- fbcideas_migusr2 hours agoNew MemberUnder Review381Views12likes4Comments
Display Table[Column] instead of Column Name in Conditional Formatting Dialogs
In large-scale Power BI semantic models, it is common to have identical column names across multiple fact and dimension tables. Examples include columns such as Status, Category, Region, Employee ID,...Manickambeeie4 hours agoNew MemberNew4Views0likes0CommentsNative SAP SuccessFactors and Active Directory Connectivity for Simplified Data Integration
Having native connectors for SAP SuccessFactors and Active Directory would eliminate the need for workarounds such as notebooks, custom scripts, or complex integration setups. Users should be able...João_Cristo5 hours agoNew MemberNew5Views0likes0Comments