User Devfiles

[l0rd]

Is your enhancement related to a problem? Please describe.

Users are not able to use Che to share their workspace definitions (devfiles) anymore. That was possible on Che 6 with factories but now we do not have this capability anymore. The only way to share a devfile is using external services like pastebin or GitHub gists.

Describe the solution you'd like

We should replace "stacks" with "devfiles" in the left menu of the dashboard.

From there a user should be able to add a new devfile that would be persisted by the Che server:

A user should then be able to view the list of his devfiles:

And for every devfile he should be able:

• edit it
• start a workspace from it
• share it with his organisation (if he has the privileges)
• get a link to the devfile to share with others
• delete it

Describe alternatives you've considered

Adding and listing devfiles with chectl
It should be possible to add and get the list of the devfiles using the command line

chectl devfile:add
chectl devfile:delete
chectl devfile:list

Adding and using devfilse from che-theia

A user should also be able to create a devfile using "share" from the editor menu:

And a user should also be able to "Open Che workspace from devfile"

Adding a devfile from the workspaces panel

A user should be able to add the definitions of his workspaces in the devfile list:

Implementation

• Adapt Factory API Adapt persistent factories to Devfile concept #16897
• [Devfile] CRUD Rest API [Devfile] CRUD Rest API #16981
• User Devfile UI User Devfile UI #17914
• Complete remaining after merging 17843 PR Complete remaining after merging 17843 PR #17911
• Record extra information for user devfiles Record extra information for user devfiles #17912
• Allow to use user devfiles in factories Allow to use user devfiles in factories #17913

[skabashnyuk]

@l0rd From the server API point of view, we are talking about the devfile registry with editing/sharing capabilities? That would be the second registry that would work alongside a read-only registry?
Or we talking about Factory API with replaced workspace config with devfile content?

[l0rd]

@skabashnyuk I would say Factory API. But I don't have a strong opinion on that.

[sunix]

In addition to that, it would be nice if we could track a history of devfile that has been used to instantiate workspaces:
So each time the you start a workspace from https://<cheurl>/factory?url="https://github.com/sunix/myproject"

• I would like to like Che to track these factory urls
• be able to have a list of previous factory url that have been tracked
• be able to rerun any of these factory URLs.
• be able to clean the history, edit, remove, manually add

Typically, from the dashboard, the user may want to access to devfiles that are located in there git repo and not having find and go to that repo (maybe many repos in the user organisation ...) , copy the url and go back in Che, start the workspace.

So basically, it would be an extension of the current proposal but using external devfile (in git repo) and not only devfiles stored in our database.

[l0rd]

@sunix your use case is a valid one. We need to support it. This is the list of "recently used devfiles". Those can be external (from a gist, pastebin, github...) or internal (factories and workspaces).

Regarding where in the Dashboard we should have a list of "recently used devfiles" I see many options:

1. In the "Get started" page
2. In a new "History" page
3. In the "Devfile" page under an "History" tab
4. In the "Workspaces" page under an "History" tab

I would like to review that with @beaumorley before we take any decision on that.

cc @gorkem

[skabashnyuk]

@sunix we already tracking stack or devfile from which workspace was created

[l0rd]

cc @RickJWagner

[beaumorley]

It seems like there may be two use cases here:

1.) User want to see recent devfiles which are any devfiles either stored in our database or external. They just use the same ones and want quick access to them.

2.) User want to have access to their external devfile links because it is hard to find them again. May or may not be used often. They are OK with drilling in a little for these since it is better than searching for them on some company server elsewhere. May/may not want to manage them.

Is one more important?

• recent - last 3 (or whatever) either internal or external sourced
• history - history of devfiles you used that may be longer. We could indicate the external ones with some kind of logo if they were in a list. This is more appropriate for a manage/add/remove feature.

In the "Get started" page

I would probably keep the getting started page as simple and not add it here.

In a new "History" page

This is interesting. We currently have "Recent Workspaces" (kind of a history as well) showing up in the side nav. We could expand that to include "Recent Devfiles" underneath. This is nice because it is one click. Maybe this is the last 3 Devfiles whether internal or externally sourced?

In the "Devfile" page under an "History" tab

This seems like a clean place to put a more exhaustive history of devfiles. This could have the add/remove/edit options if we thought they were needed.

In the "Workspaces" page under an "History" tab.

Knee jerk I think in Devfile makes more sense but would want input on this.

[SDAdham]

Hello @l0rd ,

What is the difference between Devfiles and Factory?

Please correct me if I'm mistaken:

• Factory should contain all the custom devfiles controlled by the organization that's building them.
• Stack is the ready-devfiles that's provided by Che to help users to kick-off any environment and try out che for different environments & programming languages (I'd suggest keeping this always separated from the custom factory Devfiles)
• Devfiles? I see this more of better to be done in Factory without changing names?

Also, the highlighted Open from the screenshot you provided, should be for Open file for the original functionality and this is being used. I'd suggest a new menu item Create new workspace with a submenu to From file, From factory, or From Stack if you are suggesting this to make more sense. Where:

• From file >> Browser open file
• From factory >> Command palate >> list factory devfiles
• From stack >> Command palate >> list stacks

[sunix]

@SDAdham
Factory is the ability to create a new workspace out of a template: we used to have a factory section in the dashboard where we were showing workspace config (prior to devfile) that could be triggered with a URL. Now you can provide an external devfile to a factory url to generate a new workspace out of it.
So I would keep word Factory for a way to generate new workspaces from a devfile.
Devfile to the file that would be used by factories or any other mechanisms.

[pdaverh]

How will "Share with team" and "Share with organization" work, as concept of organization in Che is not planned for enhancements. Wouldn't it be easier to push a workspace definition as devfile to a git repo (private or public) where the source for the project lives, and then have team members pick it up from there? Team members will have access to that same source repo, and org admins could move files from one git repo to another.

[pdaverh]

I'm confused between three proposed options to use devfiles - Getting started (the stacks are devfiles), Workspaces->Add (devfiles), and Devfiles.

[l0rd]

How will "Share with team" and "Share with organization" work, as concept of organization in Che is not planned for enhancements.

This issue wants to enhance the concept of team and organization in Che. It will be possible to share a workspace definition with a restricted group of people (a team) or with every Che user (an organisation). And those devfile lists can be edited from Che dashboard. Currently instead there is one unique list static list of devfiles shared across all users: the devfile registry.

What is missing in this issue is a clarification of the relationship between these new devfiles lists with the one imported from the devfile registry. One option would be that the devfiles in the registry will be the used as the initial list of organization level devfiles.

Wouldn't it be easier to push a workspace definition as devfile to a git repo (private or public) where the source for the project lives, and then have team members pick it up from there? Team members will have access to that same source repo, and org admins could move files from one git repo to another.

This issue is about a particular use case: allow to manage the list of devfiles visible from the dashboard. These are devfiles that do not live in a particular git repo (like the ones that are currently in the devfile registry).

But I think that you are evoking 2 interesting use cases that we have not covered:

SCENARIO 1. A developer setting up the Che workspace for a project and wants to contribute the devfile to the project git repo. In this case he should go trough the contribution flow of the repo (open a PR / merge request) and that, in my opinion, should happen from inside the IDE (theia).

SCENARIO 2. When an developer/team/organization persists its devfiles in its git repositories we should allow to import the repository in the personal/team/organization devfile lists. Those should be references to the devfile rather than copies so that updates to the devfiles can only happne in the git repo.

This second scenario looks critical indeed.

I'm confused between three proposed options to use devfiles - Getting started (the stacks are devfiles), Workspaces->Add (devfiles), and Devfiles.

Here is how I see the differences in those 3 pages:

Getting started
This is a list of Team and Organisation devfiles only. This is the landing page. A developer can start a workspace with 1 click from here. And if a developer needs to manage this list (and has the privileges) he needs to go to Devfiles -> Team or Devfile -> Organization.

Workspace -> Add to Devfiles
This is a button that allows developers to import a workspace devfile into one of the Devfiles list (personal/team/organization). When running a workspace from an external devfile (that is in a git repo, or in a gist), that devfile is usually lost when the workspace gets deleted.

Devfiles
This is a page to manage 3 lists of the devfiles that are visibile at different levels (personal/team/organisation)

[l0rd]

After discussing with @skabashnyuk and @sleshchenko I have updated the description of this issue to remove the term "team" and leave only "organization".

[sunix]

@sleshchenko @l0rd I guess this is the next item after the dashboard-next work?

[l0rd]

@sunix this one is blocked because we do not have a story for create teams and users roles from the dashboard. I think that what should come first in dashboard-next is the creation of configuration/credential secrets (that currently has to be done manually). cc @sympatheticmoose

[sunix]

@l0rd @sympatheticmoose OK I see, OK to have that after the creation of configuration/credential secrets,

Also, we could split this issue: we could start to have at least the feature for a single user

• Add git repos/devfiles that have been used recently to a list in User Devfiles page.
• Be able to start any devfile/repo from that page
• Be able to edit these devfile in that page (edit, rename, delete).

[sleshchenko]

Removed noteworthy since it's not such for time being, I believe. Please return back if I'm wrong.

[l0rd]

Removed noteworthy since it's not such for time being, I believe. Please return back if I'm wrong.

@sleshchenko 👍

[che-bot]

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.

[l0rd]

Closing this issue. Until we do not implement organizations we cannot do much anyway.