Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] devfile v2 projects and attributes

A devfile with two projects: one that should be resolved, + another git repo

To keep things simple I would not support such a use case. It looks like a corner case and we have other more urgent things to deal with honestly.

OK but it is not a corner case: it is very common to have projects splitted in several git repos. A good example is Che itself. When you work on che-theia, you may want to checkout https://github.com/eclipse-theia/theia  and https://github.com/eclipse-che/che-theia. I can find a lot of projects like that. "core" project in one repo, "front" in another, etc ...


The name of the devfile project and the name of the repo are 2 different things. There should be no issue to have something like this:

(...)
projects:
  - name: sample
    git:
      remotes:
        origin: "https://github.com/l0rd/sample-fork"
(...)
 
Yes it should be 2 different things but at some point the "sample" name is generated from the git repo. So that would not work if the original repo is https://github.com/myorg/sample-fork as the generated name would be "sample-fork"

 
We definitely needs a way to tell Che that a project should be resolved, something like:

projects:
  - importRepo: true
    attributes:
      rootFolders: "rest-json-quickstart,rest-client-quickstart"

With 2 projects:

projects:
  - importRepo: true
  - name: che-devfile-registry
    source:
      type: git

With 2 projects and a custom name:

projects:
  - name: sunix-devfiles
    importRepo: true
  - name: che-devfile-registry
    source:
      type: git

WDYT ?


Sun Tan

Senior Software Engineer

Eclipse Che - CodeReady Workspaces @ Red Hat

also Paris JUG Leader

Red Hat Paris

sutan@xxxxxxxxxx    
M: +33621024173    

@__sunix_   me  


On Wed, May 5, 2021 at 12:32 PM Mario Loriedo <mario.loriedo@xxxxxxxxx> wrote:
I am +1 to have something like the following devfile in the git repo

(...)
projects:
  - name: quarkus-quickstarts
    attributes:
      rootFolders: "rest-json-quickstart,rest-client-quickstart"
components:
(...)

And then the resolver completes the projects section with the repo and branch:

(...)
projects:
  - name: spring-petclinic

I did a typo in my sample, the name even when the resolver completes the projects section should be unmodified (i.e. "quarkus-quickstarts")
 
    attributes:
      rootFolders: "rest-json-quickstart,rest-client-quickstart"
    git:
      remotes:
        origin: "https://github.com/quarkusio/quarkus-quickstarts"
      checkoutFrom:
        revision: "main"
(...)


On Tue, May 4, 2021 at 7:53 PM Angel Misevski <amisevsk@xxxxxxxxxx> wrote:
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
>

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev

Back to the top