The devfile registry should allow referencing external devfiles or external git projects (that may contain devfile.yaml)

[sunix]

Is your enhancement related to a problem? Please describe.

At the moment, the devfile registry can only use self referenced devfiles ( referenced in the same own repo). But for some team it may be hard to maintain these devfile in a single git repo. It may also be easier to maintain the devfile.yaml that is in the project repo it self.

Describe the solution you'd like

in the devfile meta.yaml of a devfile registry, we should be able to indicate an external url of

• a raw devfile
• a github project
• a git project

Basically all that the factory service is supporting with the url attribute.

[l0rd]

@sunix when you say "For some team it may be hard to maintain these devfile in a single git repo" what are you thinking about? How does teams are maintaining a devfile if not in a git repo?

I am asking because even in the scenario that you are describing the team will need to:

• publish the devfile somewhere (and hopefully version it as well)
• maintain (create, update) the devfile meta.yaml in a devfile registry git repo
  and that doesn't look simpler then maintaining the devfile.yaml in the git repo itself.

[sunix]

Take the example of a big project ... like Che:
you have

• the platform team
• the deploy team
• the plugin team
  etc...

and they all share the same devfile registry git repo. For all the git project they are owning, there are different permission policies: reviewers/commiters roles are different from one git repo to another.

But if you rely on only 1 git repo for all the devfiles, how do you deal with all the different devfiles that should be own by a specific team ? It will be a nightmare to all the developers in the process of reviewing/pushing/changing a devfile in the registry git repo.

• platform team may have sergey as a reviewer
• plugin team may have Eric as a reviewer
  etc...

Who would be the reviewer for the devfile registry ? to me, each devfile should have the corresponding reviewer of each team.

Some teams would prefer to update their devfile that would be located in their own repo where they work. They would have the same permission and role regarding push/pull/review on the repo.
In the current situation, if a team would like to modify a devfile, they should go through the policy of the devfile registry git repo ... this is really annoying.

The meta.yaml file could just be created once and update not very often. No need to touch it if you just update the devfile.

Also changing the devfile in your own git repo would not required to redeploy the devfile registry.

[l0rd]

The devfile registry is for sample stacks, not as a registry of teams projects (in those cases the devfile lives in the repository root folder).
And anyway, in the hypothetical case that different teams are responsible for different sample stacks, the OWNERS file you let you specify distinct ownership, even with a single GitHub repository.

[sunix]

What if teams are using Bitbucket and not Github? there is no such OWNERS things ...

If devfile registry is just for sample stacks, why do we make it such a big piece of our architecture. Why do we allow teams to provide their own devfile registry? Che should be the Next-Generation IDE for developer teams so the devfile registries should be for team projects as soon as they are used by developer teams.

Sample stacks are useful only when Che is being evaluated. But once a organisation is choosing to adopt Che, the devfile registry is the good place to list all the projects to be used daily. As you say, the devfile would live in the repository root folder. That is the purpose of this proposal to allow referencing these ones.

[l0rd]

Your ownership problem can be solved with multiple devfile registries: one registry per team.

I am not convinced about the value of having the Dashboard "Getting Started" populated with real projects instead of samples.

[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.

[sunix]

Closing in favor of #16875