Reimplementing forking
Problem to solve
As a user I want to be able to fork any kind of project successfully. The current implementation does not let users pick the namespace nor works reliably for data projects, and absolutely does not work for code projects.
Following the complete scenario.
Data projects:
-
Creating any pipelines creates branches next to entries for data sets / viz / experiments. Only the branches and not the other entries should be forked (only the data). -> completed -
An option should be available in the settings that will store the output of experiments in branches together with the artifacts (to be designed). At the moment, the output (e.g. model of several 100s of MBs) is stored as artifacts AND within the branch. -
Prior to forking, the user should select the namespace he wants to fork to #1065. See design: #375 -
The forking history should be present and tell the user, that he already forked a project. Currently, forking a project twice will end up in an error. The forking button should changed to "forked" and link to the forked project once it has successfully been forked. #1064 (closed)
Code projects:
- Code projects should follow same logics as data projects, only branches are forked.
- Published code projects that are being forked do NOT include data processors and no publication history. They are empty (only the repo with all branches are transfered). No "published" status is transfered.
Intended users
User experience goal
Proposal for Technical Solution
Permissions and Security
Documentation
https://docs.gitlab.com/ee/api/projects.html#fork-project
Availability, Testing & Test Cases
What does success look like, and how can we measure that?
Additional Notes
What is the type of buyer?
Is this a cross-stage feature?
Links / references
/cc @si-ge-st
Edited by cpmlreef