Re: [che-dev] devfile v2 projects and attributes

[Angel Misevski <amisevsk@xxxxxxxxxx>]

On 2021-05-04 10:02 a.m., Florent Benoit wrote:
> Hello,
>
> Convention for a devfile stored in a repository is to not include 
> projects entry.
> It's because the factory resolver is adding on the fly the projects 
> entry based on the current branch/repository location like a fork. (If I 
> fork a repository and open the forked devfile.yaml I do want to have the 
> forked repository imported and not the original one)
>
> On the other hand, we may want to describe for a given project, the 
> 'project roots' that we want (like for example adding one or two 
> subfolders as being workspace root in the IDE) and we also want to 
> attach some IDE configurations like vsCodeLaunch/vscodeTask and these 
> settings fit in the free-form attributes section of projects.
>
> So it seems that we've like conflict of interest between those two as we 
> want to add settings specific to a project but also we do not want to 
> add the full link to the project.
>
> This is why I was wondering if we are able to have a placeholder entry 
> in projects that would allow us to add some specific configuration but 
> not match the final location of the project being cloned.
> And the resolver would just override/complete the projects entry and not 
> add a new one.

I haven't thought about it too deeply, but I wonder if the recently 
added global variables feature could be reused for this. With PR [1], 
devfile 2.0 supports a top-level field "variables" where each key can be 
automatically replaced throughout a devfile, so something like

variables:
  mainRemote: origin
  revision: main
projects:
  - name: template-project
    git:
      remotes:
        origin: https://github.com/upstream/project
      checkoutFrom:
        remote: "{{mainRemote}}"
        revision: "{{revision}}"

would do what you expect it to. Forked projects could automatically add 
a remote and set the `mainRemote` and `revision` fields accordingly -- 
e.g. if I provide a factory URL for

  https://github.com/amisevsk/devworkspace-operator

we could automatically update the devfile in the repo to add a remote

  amisevsk: https://github.com/amisevsk/devworkspace-operator

and set `mainRemote: amisevsk` to checkout my version of the code.

(Note that the variables feature isn't yet implemented in DWO, though...)

[1] - https://github.com/devfile/api/pull/352

> In devfile v1 we could have an empty location but with devfile v2 we 
> have git/remotes and for remotes field "The remotes map which should be 
> initialized in the git project. Must have at least one remote configured"
> So I don't see how to use an empty remote/empty project there to match 
> this use case ?
>
>
>
>
>
> _______________________________________________
> che-dev mailing list
> che-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev