We’re testing different approaches to collaborate using renku lab.
The renku web ui offers a button to fork a project. But there seems to be no mechanism to create a pull request from a previously forked project.
Of course you could always to these operations in gitlab. We were just wondering, what the intended workflow might be, as there is a fork- but not a PR-control on the web ui.
Good question. The use case we are primarily seeing with forking projects is a bit different than the typical GitHub/GitLab fork use case.
We see it being used in the teaching of courses. The instructor creates a project with all of the materials necessary for the course; the students fork this project to get their own copy of it for doing their work in the course. In this scenario, we do not expect contributions from the fork back to the source project.
Overall, the guiding principle in the UI has been to support features and use cases that are different from GitLab, and defer to GitLab for things that are well-supported there. This has the unfortunate side-effect that it leads to an erratic user experience, especially for power users that want to take advantage of GitLab features, but it allows us to dedicate our resources on the differentiators.
We are revisiting this decision and intend to duplicate some GitLab functionality to provide a smoother experience to our users, and we would be happy to hear feedback, especially about things that are in your daily workflow that you would like to have better supported in Renku.
The instructor creates a project with all of the materials necessary for the course; the students fork this project to get their own copy of it for doing their work in the course.
Renku is a great tool for this scenario. It is now already used for that at our university.
and we would be happy to hear feedback, especially about things that are in your daily workflow that you would like to have better supported in Renku.
Currently we plan to collaborate with branches, not forks. One feature that might come in handy, is the possibility to select target branch in a merge request. Currently this seem hard coded to “master”.
Our priority is to support the more basic git-based workflows, but I think in this case, supporting a more advanced scenario isn’t in conflict, and it should be possible to do this without increasing the burden on users that are served by the simpler workflow.
One question – right now, we render jupyter notebooks side-by-side for comparison when merging branches (diffs in notebooks can be hard to understand in GitLab), but to see diffs of other files, it is necessary to go to GitLab. Would you like to see diffs of all files for your use case, or are you describing a notebook-driven scenario.
I stumbled over this discussion when wondering how to best deal with issues and merge requests. We want to use renkulab to collaborate on projects and track provenance and all changes. Sometimes we use forked repos, but mostly we collaborate on the same repo and use branches, which we merge into master when happy, while closing any associated issues. What is the best way for doing this in renkulab? Forks through renkulab, issues in the main gitlab project and merge requests from the forks to the main project, or is it possible to collaborate on one project and have different branches and merge requests from there?
Yes, it is possible to have different branches and merge requests in one project.
This way of working is supported in the RenkuLab UI (see the collaboration tab). If you create a branch and go to the Collaboration/Merge Request tab, you will be asked if you want to create a MR for this branch. In the RenkuLab UI, we do not present full diffs of the branches, though. We only show a listing of which files were added/removed and which files were changed for most file types. For notebook files, though, we show the full old and new notebook content. This may be sufficient for you, if not, you can always view the diffs in GitLab (there is a link to take you to the GitLab page).
The fork-based workflow is not yet supported in RenkuLab. For that, you would need to go to GitLab, but there is interest, we will certainly be happy to look into supporting it in RenkuLab.
Yes, this is correct – RenkuLab issues and MRs are GitLab issues and MRs, so you can move between the two UIs to take advantage of both feature sets.
ATM, you can do fork-based workflows using the GitLab UI, but you are absolutely right, we really should do a better job supporting fork-based workflows. We have plans to improve the collaboration features and make it easier to browse branches and forks, and it would make sense to incorporate MRs from forks.