Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initialize session with git repo #348

Open
iyannsch opened this issue Sep 5, 2024 · 8 comments
Open

Initialize session with git repo #348

iyannsch opened this issue Sep 5, 2024 · 8 comments
Labels
enhancement New feature or request

Comments

@iyannsch
Copy link

iyannsch commented Sep 5, 2024

Is your feature request related to a problem? Please describe.

When users start a new session through the landing page, they still have to manually clone a git repo once the IDE has loaded. This situation leaves a lot of potential, because Theia is highly configurable before a user has contact with it: Install plugins, install dependencies and configure the whole experience. However, the user still has to manually search for the correct clone URL, start up a terminal, find git cloning credentials, and finally clone via CLI (or VSC UI).

Describe the solution you'd like

I imaging a Theia extension that would be installed by default. It should read values provided by the landing page during the "SpawnRequest" and utilize VSC's git plugin to initiate the cloning procedure before the user even enters the session.
Regarding the values, we'd only need the CLONE_URL and a CLONE_TOKEN but probably user-password or ssh auth would also be nice.

Describe alternatives you've considered

As an alternative, we could implement the respective Theia Plugin ourselves as part of our organization's VSC extension. This mixed responsibilities though as this feature would not necessarily be required on a local setup of VSC.

Cluster provider

No response

Additional information

There has already been some effort in this regard (#182) and currently there is a lot going on in the background. Still I think, this would be a powerful addition unlocking a lot of new use cases for Theia.

@iyannsch iyannsch added the enhancement New feature or request label Sep 5, 2024
@lucas-koehler
Copy link
Contributor

Hello @iyannsch ,
thanks for the proposal. We discussed this and came to the conclusion that there are multiple considerations regarding how the credentials are managed, i.e. prompting the user or pre-configuring them via Kubernetes secrets.
To get a better understanding what is needed , could you please elaborate on the following questions regarding the usage of auth credentials?

  1. Are credentials only needed to clone the repository? Or are users expected to push back to the cloned repository using the provided credentials?
  2. Is the token unique to each user or is there a shared token for all users?
  3. Is is acceptable or maybe even preferable to prompt the user for the credentials? Or should they be pre-configured?
  4. Is the clone SSH based? If yes, does the key need to be available within the IDE?

Thanks!

@iyannsch
Copy link
Author

Thanks for picking up this issue again! In answering the questions, I'm always only talking about our very specific use case. Please keep in mind that this is a very isolated and educational context we work in.

  1. We want to clone and push with the same credentials to the same repo
  2. As each student has a personalized repository, the token is never shared and might be re-generated/changed from one session to another even though the repo itself stays the same.
  3. We aim to integrate Theia as closely to our usual workflow as possible. This suggests a comparison between fully-configured VSC locally and Theia online. We'd love to pre-configure the clone token during session creation (and inject it through a redirect-parameter when the user opens the landing page). Asking the user for credentials (this would be mail-password and not token for usability reasons) is less preferred.
  4. Our VC system offers Email/Password-, SSH-, and Token-based interaction both in cloning and pushing. Due to the short-lived character of a Theia session I figured that Token-based cloning would be most comfortable. Using SSH keys entails either getting a registered private-key from the user or communicating with the VC system to register a dynamically created Theia-Only key.

Looking forward to your opinion on those reasons :)

@lucas-koehler
Copy link
Contributor

Hi @iyannsch, thanks for your elaborate and quick feedback :)

  1. We want to clone and push with the same credentials to the same repo
  2. As each student has a personalized repository, the token is never shared and might be re-generated/changed from one session to another even though the repo itself stays the same.

Using credentials that allow clone and push and are unique to a user definitely makes sense. I think this is the most common use case for others outside education, too.
Depending on how the token is "stored" in Theia Cloud (e.g. as a secret), updating it frequently might make things a little more complicated. However, it makes sense to not use one token "forever" (or for a very long time).
Thus, it seems sensible to me to facilitate changing the tokens frequently. Depending on the effort this could be a follow up enhancement though.

  1. We aim to integrate Theia as closely to our usual workflow as possible. This suggests a comparison between fully-configured VSC locally and Theia online. We'd love to pre-configure the clone token during session creation (and inject it through a redirect-parameter when the user opens the landing page). Asking the user for credentials (this would be mail-password and not token for usability reasons) is less preferred.

Alright, this means from Theia Cloud's point of view, the landing page just has these credentials available and wants to somehow configure them for the session. I assume either a separate REST service call or directly handing it over during session creation would be acceptable. Is this correct?

  1. Our VC system offers Email/Password-, SSH-, and Token-based interaction both in cloning and pushing. Due to the short-lived character of a Theia session I figured that Token-based cloning would be most comfortable. Using SSH keys entails either getting a registered private-key from the user or communicating with the VC system to register a dynamically created Theia-Only key.

I see, I agree that using a token is probably easier. Especially since you usually want to password protect private SSH keys that the user then would need to unlock. I think we'll have to see how well it works to preconfigure that while avoiding the user to do anything explicit. However, this should work for tokens. For instance, this could be configured in the git credentials store.

All in all I think your requirements seem quite universal. The team and I will see what is a good way to get the tokens/secrets into Theia.

@lucas-koehler
Copy link
Contributor

Implementation sketch:

  • Configure secrets for credentials via new REST service method. Secrets are annotated to the user that created them.
  • Mount credentials from secret into session pod
    • Potentially save the whole git credentials config in the secret and mount it as a file in the user home
  • Initially clone repository in init container. This ensures the repo is fully cloned once the session is ready.

@iyannsch
Copy link
Author

Your approach sounds very nice! Do you already have a timeline for those features so we can align internally and maybe stop searching for alternatives for now?

Alright, this means from Theia Cloud's point of view, the landing page just has these credentials available and wants to somehow configure them for the session. I assume either a separate REST service call or directly handing it over during session creation would be acceptable. Is this correct?

Your assumption is correct and aligns well without sketch ☺️

@lucas-koehler
Copy link
Contributor

Hi @iyannsch, there is no timeline for now unfortunately as this is not trivial to implement. We'll need to prioritize this first.

@iyannsch
Copy link
Author

Sounds great! One thing that I just noticed and wanted to clarify: In our use-case not only the token/key differs across users but also the repository. It will contain mostly the same files throughout all student repositories but technically each student got their own repository (different URL, different token).

@lucas-koehler
Copy link
Contributor

Thanks for clarifying. I do not think this makes a difference in effort as we want to make the repository configurable anyway :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants