Community
Participate
Working Groups
The scenario we would like to address with the API is not only allowing to clone a git repository, but also be able to point to a subfolder in the repository and make a project out of it. There are at least 3 approaches we can consider implementing the API: 1) Add API for calling POST on /git/clones, which would clone the given repository into a hidden location in workspace. Return the location as a path in the filesystem in the response. And then used that location to link a project, call POST on /workspace/<id> with the ContentLocation returned in the previous step + an optional path in the clone. This approach reuses the existing API for creating projects, which is great, but the fact than anyone knowing location of the newly created clone can link to it may be considered a major drawback. 2) Similar to 1) but instead of returning location in the filesystem of the newly created clone the server would return a location in /file/<id> form. This would require us to modify the current API for creating project so it allows linking using a server path. What we gain doing that is an ability to verify if the user can link to the location he provided. 3) Finally, we could squash both operations (cloning and adding a project) into a single call. Doing POST on /git/clones would not only create a clone (in the hidden location) but it would also create a project and link it to the clone.
I would lean towards 3). If you keep them separate, then you need this new concept of a "cloned repository that is not a project", which raises questions of how to access/modify/delete/manage authorization on such a thing.
(In reply to comment #1) > I would lean towards 3). If you keep them separate, then you need this new > concept of a "cloned repository that is not a project", which raises questions > of how to access/modify/delete/manage authorization on such a thing. Actually there is option 4). - We create a clone first and this operation should not create any folder in the workspace. The clone location is /git/clone/[cloneId]. Its children locations are /git/clone/[cloneId]/[path] - Then you can go to any node in the clone, call POST on it and pass the name of the top-level folder to create - Even better would be to have a special importToWorkspaceLocation field in the git clone representation. This location would be used to import part of the clone to the workspace. It is a similar concept to import/export on files.
(In reply to comment #2) Tomek, as we chatted yesterday we would need GET /git/clone implemented that would return the list of existing clones. We need that to populate the git clones view.
I implemented 1) with 543ff2fa9a183237e0ef58a42d85886450c2b831, keeping in mind that this is a temporary solution. Next I thnik I will switch the implementation to 4) but first I'm going to add GET /git/clone from comment 3.
(In reply to comment #3) > we would need GET /git/clone implemented that would return the list of existing clones Fixed with 24fc6dd3bcfb16b47097b6234401313022b2b9f0.
The initial work is done. We have new bugs raised against remaining issues.
