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

Che to perform git clone of projects to reduce errors and for easier integration with editors #15973

Closed
1 of 5 tasks
benoitf opened this issue Feb 10, 2020 · 5 comments
Closed
1 of 5 tasks
Labels
engine/devworkspace Issues related to Che configured to use the devworkspace controller as workspace engine. kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. roadmap/6-months Epics that are planned to complete in the medium term (within 6 months)

Comments

@benoitf
Copy link
Contributor

benoitf commented Feb 10, 2020

Cloning projects lifecycle.

Today, the clone operation is done when user is opening the workspace in Eclipse Theia.

So it means, that we delay the clone operation at the end, when a client is connected.

It's mostly due to handle the 'private' projects where authentication is required and then user is prompted with github oAuth for example.

That said, there are several drawbacks to do this at the final step.

  • clone is only performed for Eclipse Theia (if you're using Jupyter, Eclipse IDE, etc editors the project is never cloned)
  • it takes time. Let say the workspace is created, during the time that Theia is loaded, the project could have been already cloned.
  • language servers may be initialized too early.
  • in case of Async PV for workspace: enabling feature (toggle) #15960 sync PV storage, you need to know if some files have restored or not when the IDE is loading to not clone again. But if clone has already happened it's the same loading sequence.

Workspace startup can be faster if it's done earlier.

Private repositories and handling

We could clone in init container, etc but it may work only for public repositories.
Workspace loader could handle as well the clone operation for private projects as it's used by all editors.
Init containers could handle also the clone operation if we've stored previously some tokens.

How are we going to address it?

  • Projects clone should happen before other components are started
  • User should be able to manage his Git credentials and SSH Keys from the dashboard (c.f. User Preferences-Adding External Accounts)
  • Workspace loader should fail to start the workspace if the user does NOT have the privileges to clone the repository (c.f. devfile resolver)
  • Workspace loader should look for a devfile in the project repository before creating the DevWorkspace CR (devfile resolver)
  • Workspace loader should authenticate user against GitHub, GitLab and Bitbucket to in projects retrieve devfile
@benoitf benoitf added the kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. label Feb 10, 2020
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Feb 10, 2020
@ibuziuk ibuziuk removed the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Feb 10, 2020
@ibuziuk ibuziuk added this to the Backlog - Epics milestone Feb 10, 2020
@ibuziuk
Copy link
Member

ibuziuk commented Feb 10, 2020

@benoitf which team is expected to work on this epic?

@benoitf
Copy link
Contributor Author

benoitf commented Feb 10, 2020

For now it's unassigned let's assign to devex

@l0rd
Copy link
Contributor

l0rd commented Jul 30, 2020

When working on an implementation we should think about something that will work with devworkspace operator and devfile 2.0 too.

@l0rd l0rd added the engine/devworkspace Issues related to Che configured to use the devworkspace controller as workspace engine. label Dec 18, 2020
@l0rd l0rd added the roadmap/6-months Epics that are planned to complete in the medium term (within 6 months) label Mar 26, 2021
@l0rd l0rd changed the title Move clone operation earlier in the lifecycle of a workspace Che to perform git clone of projects for easier integration with alternative editors such as IntelliJ Mar 30, 2021
@l0rd l0rd changed the title Che to perform git clone of projects for easier integration with alternative editors such as IntelliJ Che to perform git clone of projects to reduce errors and for easier integration with editors Mar 30, 2021
@l0rd
Copy link
Contributor

l0rd commented Sep 8, 2021

I am removing this as part of "DevWorkspace Integration - STEP3" milestone as we are going to include #20432 instead.

@l0rd l0rd removed this from the DevWorkspace Integration - STEP3 milestone Sep 8, 2021
@che-bot
Copy link
Contributor

che-bot commented Mar 7, 2022

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 7, 2022
@che-bot che-bot closed this as completed Mar 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
engine/devworkspace Issues related to Che configured to use the devworkspace controller as workspace engine. kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. roadmap/6-months Epics that are planned to complete in the medium term (within 6 months)
Projects
None yet
Development

No branches or pull requests

4 participants