Content
Added by Gabriel Mazetto about 9 years ago
Will you consider fixing “repositories” feature and integration with openproject?
What I would like to see fixed is git support.
I’m willing to help with merge requests if you give me green light to the following proposal:
- I will implement a way to git clone remote bare repositories to a local copy in "#{Rails.root}/repositories/#{project_id}/#{repository_id}.git
- I will implement a worker using Sucker Punch to clone repositories (https://github.com/brandonhilkert/sucker_punch), as it’s the most portable, well written, easy to implement asynchronous processing library without requiring extra process or redis backend (but I’m willing to support sidekiq if you also send me a “go for it”.).
Here is something I don’t know yet how it should be done (maybe more then one of then):
- Update can be a async task that is triggered by a “refresh” button
- API endpoint to trigger it and get “last time updated value” (check progress? how?)
- Webhook for Github, Gitlab and Bitbucket (maybe something plugable? how?)
- Rake task (already exists, and can ben scheduled to the cron… maybe easy the process by integrating “whenever” to the project)
Extra:
I’m also interested in migrating (most if not all) git support to https://github.com/libgit2/rugged which is integrated with libgit2.
Replies (4)
Hi Gabriel,
thanks your post and your interest in improving OpenProject on a technical level, we appriciate very much.
Our current implementation for reposititories is quite limited and although git functionality is still in the code (in lib/redmine/scm/adapters/git_adapter.rb) we don’t officially support it. Therefore, if you haven’t had a look that specific part of the source code I would suggest you do so and see whether slight modifications can solve your use case already. You’d probably also have a look at /extra/svn/reposman.rb which, despite its file location, also supports git through the —scm parameter. We would be happy to accept pull requests to fix the last pieces to make everything work smoothly. It doesn’t support fetching remote repositories, though.
In Summary, here’s what’s already there (purely for documentation puposes):
Nevertheless, we aren’t satisfied with the current solution of our repository code and already have open requests on implementing mercurial again (https://www.openproject.org/work_packages/2291). We think, the best approach is to modularize this part of the code so each repository type could be implemented as a separate independent gem.This requires developing the supporting code first, most likely during extraction of an already implemented scm adapter like subversion. We cannot maintain all scm adapters that people might want to use and by having them in separate gems we could delegate that responsibility to motivated community members. We would just make sure that the repositories abstraction works well and provide a reference implementation. Ultimately, the approach would also lead to the possibility of having more than one adapter that implements a single scm (e.g. one by shelling out, the other by wrapping libgit2). This would ease the process of using more advanced adapters as they can just be switched out as needed.
Long story short, if you can help us implementing this kind of abtraction while implementing the libgit2 based approach, we would support it. This would also bring us closer to supporting mercurial again and still keeps the core clean of any modules that are’n required by the majority of users. Maybe you and Chris Larsen (https://www.openproject.org/work_packages/2291) are able to team up on this.
Please tell us what you think about the above and whether you find the topic interesting.
This became rather long, let me also present my thoughts on the other points you mentioned.
Cloning remote repositories to local is not supported at the moment. but once you have it local the above applies.
Asynchronous processing of tasks related to repostiories is desireable. Currently async jobs are done throguh delayed_job and we would like to stick with it for the near future. As far as I can tell, sidekiq and sucker_punch use parallel threads instead of processes. As OpenProject is currently not in a thread-safe state it will be difficult to ensure there aren’t any problematic side-effects. This means, we would much more prefer asynchronous jobs written using the delayed_jobs library.
Whenever you go to the repositories#show action, the database is populated with the new commits that happenend when you hit that page the last time. it’s synchronous and not triggered by any other hooks. For remote repositories, hooks would be very desireable.
A decent whenever file would be a great help for anyone that want’s to deploy OpenProject by him or herself.
Implementing the git repository adapter with libgit2 bindings is a very good idea. We would like to see that in OpenProject.
I hope, that helps you to understand the current implementation better and makes clear where we eventually want to be regarding repositories and OpenProject Core code in general.
Let’s keep this discussion going!
Best regards,
Martin
Hi Martin,
Martin Linkhorst wrote:
does “still” mean repository/source code integration will be dropped some time?
Michael
The goal is to strip the existing repository adapters in the OpenProject Core down to an abstract adapter module that is extended through plugins/gems for multiple revision control systems.
Until that abstraction is properly defined (and at least the counterparts for Subversion and Git exist in a stable version), these functionality will probably remain in the core.
You can find a relevant epic WP concerning this topic at https://www.openproject.org/work_packages/12808
Best regards,
Oliver
Are there any news on this front? I would be interested in integrating Fossil (http://www.fossil-scm.org) with OpenProject, but I lack knowledge about Rails and Redmine to write up some code. If a simpler interface with clearly defined API would exist, it would certainly be a big help.