🤔 Problem

Users need a way to customize their project environment. This is something we hear all the time from users, straight from the beginning of opening the 2.0 beta, and including being one of the most frequent questions we got at the ORD Hackathon.

Easy environment customization is also one of the most user-valued pieces of Renku 1.0 (yes, even with all the UX odd-ends that process has!). Specifically, users value:

Everyone on my project gets the exact same environment when they start a session. Everyone, every time.
I can create an image in my Renku project, and use that image outside of Renku.
and I can do all of the above without having to know Docker! (or at least how to build dockerfiles)

Plus, some related constraints:

We want to continue to support the standard best practice of defining an environment in a code repository.
Even better than not knowing Docker, we want this to be as easy as Binder, aka I just give you my repo and I get a working environment.
Users already complain about launch times, so we don’t want to make it any longer.

We want to continue to deliver on these key points in 2.0.

So, what’s stopping us from just porting the 1.0 system to 2.0? Learning from the last 7(?) years, it’s become clear that we don’t want to use GitLab for image building. Interfacing with GitLab for this functionality in Renku has been hard and makes for poor UX. And in the long term, we’d like to not host GitLab at all due to the maintenance load it represents.

One option we explored for achieving those value points without using our GitLab was ‣, where we explored using existing infrastructure for building and hosting images. However, the conclusion of that exploration was that this was not a viable solution (see One strategy we’ve been exploring for resolving the issue of needing to customize an environment with a set of custom dependencies has been the ‣. In this exploration, we’ve built a PoC wizard that can take any code repo and add image-building CI to it. In line with the overall mission of Renku 2.0 connecting other infrastructures, this strategy centers on using existing infrastructure for building and hosting images. However, in that learning process, we’re running into issues like whether git providers have the registry turned on, limits on hosted images, and what files to expect is already in the git repo and not. We can probably resolve these issues in ways that are understandable to us and to our most technical users, for example via documentation and error messages (”sorry, your chosen git provider doesn’t have the registry feature enabled”). However, these kind of issues are going to be hard (impossible?) to resolve in a way that is digestible to an everyday Renku user. Plus, for our most technical users, they would probably prefer to follow a documentation guide for how to set up an image build pipeline themselves in their repo over a wizard anyway. So our solution doesn’t well match the audience. All in all, we’re not seeing this direction as a promising option for our main user base. for a discussion of why not), and that the only viable solution is to keep building and hosting of images under our domain.

🍴 Appetite

6 weeks

🎯 Solution

All sketches are here: https://excalidraw.com/#room=451a2f43135b13ae9c39,MAb5JftH5YbZLXG8cBxc_w

</aside>

The core of the solution here is to add a new flow where the user can create an environment from a code repository.