-
-
Notifications
You must be signed in to change notification settings - Fork 151
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add GitLab as a sync backend #733
Comments
Nice, I'm looking forward to that sync backend! Note that there are a few Gitlab API clients: https://www.npmjs.com/search?q=gitlab%20client But if you only need this 3 API calls, it's maybe better to implement it yourself instead adding a dependency (which partly don't even work with Promises). Generic git support would be nice but considering the complicated git repo data structures that would all be needed in local storage, disqualifies that alternative for me, too. |
Hi @chasecaleb Using git as a back-end is certainly interesting. It has been requested multiple times in the suppor channels and also as GH issue (#484, #279). I'm a Gitlab user, myself. If you're going for Gitlab integration, I'd personally also access the REST API directly. We have recently moved off a selfmanaged gitlab instance to gitlab.com and it proved way easier to write code directly against the API. All libraries I tried (JS, Ruby and Python) had some caveats. However, the REST API was very clean and easy to use. The APIs you have described seem very reasonable to implement and correlates well to how organice works (simple push/pull workflow). For reference, I'll say that others have mentioned https://isomorphic-git.org/ as a good way to integrate git into organice. However, I have personally never followed up on this. To get you started, here's a good place to start: Synchronization is build using the strategy pattern which is consumed here[1]. Implementing a new backend is as easy as implementing 8 functions[2]. For Dropbox it's about 120 LOC JavaScript. I'll happily merge a PR enabling Gitlab as a back-end. Of course I'll also give support during development by answering questions and will help testing. Good luck and enjoy 🙏 |
Thanks for the quick responses and info!
Yeah, exactly. I'm planning on using browser Hmm, fascinating. I'm going to keep that in my back pocket in case I ever come across another need for it, but unfortunately both GitHub and GitLab have understandably restrictive CORS settings for Git endpoints (as opposed to regular API endpoints) so it's a non-starter in this app. References:
By the way, what is your browser compatibility policy? Particularly, do you care about IE or pre-Chromium Edge? I'm guessing not based on a quick skim through your code but want to verify. I don't see it written down anywhere, but I might have missed it. I'll be back in the next week or two with at least the beginning of an implementation in the form of a draft PR. |
Re CORS settings for Github and Gitlab: Those make sense indeed. I'll keep your links in the back pocket in case the next person requests "native git" support(; Thank you for checking out the potential opportunity 🙏
There is no explicitly written down policy at the moment. The implicit policy that we have used so far is: Make organice run on current iOS, Android as well as Firefox and Chromium on the Desktop. Fixing regressions for browser/mobile OS upgrades supercedes the need for supporting legacy browsers. The current maintainers all run current browsers. If, at some point, a maintainer comes along who is interested in keeping support for legacy browsers, there's room for that. Until then, legacy support is not an explicitly important issue.
I'm looking forward to it! Have a good time and speak soon. |
As opposed to always showing once clicked. Preparatory work for 200ok-ch#733
Make them usable for any sign in form (such as the WIP GitLab form), as opposed to specific to WebDAV. Preparatory work for 200ok-ch#733
Preparatory work for 200ok-ch#733
Version control makes this redundant. For 200ok-ch#733
As opposed to always showing once clicked. Preparatory work for 200ok-ch#733
Make them usable for any sign in form (such as the WIP GitLab form), as opposed to specific to WebDAV. Preparatory work for 200ok-ch#733
Preparatory work for 200ok-ch#733
Version control makes this redundant. For 200ok-ch#733
Reasons: - Adding GitLab as a sync backend for 200ok-ch#733, where every single file change results in a new commit. Increasing this delay means fewer commits. - Regardless of backend, fewer syncs means less network traffic and battery drain.
Closed by #734 |
I'm willing to implement this myself, I just want to make sure that there is interest in merging this feature before I spend the time implementing it.
Is your feature request related to a problem? Please describe.
As a user who stores his org files in Gitlab, I would like to be able to access these org files from organice as well.
Describe the solution you'd like
Add Gitlab as a sync backend using their API. Of note:
Describe alternatives you've considered
Additional context
I use https://github.com/simonthum/git-sync to sync between my computers, so same use case but different scenario. That's a bash script that uses
git
, whereas I'm suggesting using Gitlab API calls. Anyways, point is that the general concept of using a git repo to automatically sync org files works well so I'm confident that it will be useful here too.Interested?
The text was updated successfully, but these errors were encountered: