Handling of resources that comes from the parent devfile

[sbose78]

Handling of resources that comes from the parent devfile. Things to do:

1. When a stack is being used, it should download the files in the stack in a given registry and put them under the local source folder.
2. Devfile library has functions to download the devfiles. The behaviour should go to each parent and download the files from the parent tree.
3. In case of the file conflict caused by the same file exists in both child and parent, the files in the child devfiles will be used.
4. This behaviour should also be documented in the specification on how to handle supporting files that comes with the parent.
5. Given that the supporting files will be downloaded, we will not introduce the ${STACK_ROOT} variable. (see old description below for details)
6. This item is still targeted as part of the devfile 2.2 release

Old description for record:

Could we support the ${STACK_ROOT} variable to be able to express that a specific artifact comes with the stack and not necessarily with the source code/project ?

Example, I would like to specify that a Dockerfile build be done using the ${STACK_ROOT}/Dockerfile and not the ${PROJECTS_ROOT}/Dockerfile.build .

Such artifacts/files would be packaged and served off the devfile directory, example

• https://che-devfile-registry.openshift.io/devfiles/angular/
• https://github.com/sbose78/stack-registry/tree/sbose78-patch-1/stacks/quarkus-serverless

EDIT:
This is how tools could implement it : #55

Target Date: 09-09-2022

[kadel]

I would suggest something like ${PARENT_ROOT}, as the parent (stack) in a devfile is referenced using parent field (#25)

How would I refer to a file that comes with child Devfile.
${PROJECTS_ROOT}/Dockerfile.build is not that. At least in Devfile v1 ${PROJECTS_ROOT} is a directory in the container where the projects are cloned (by default /projects)

We will also need to reference files that come with child devfile.

A have a devfile.yaml in my repo (git://github.com/kadel/example) that specifies a parent like this

parent:
    uri: https://example.com/java/devfile.yaml

In the context of this devfile, ${PARENT_ROOT}/Dockerfile would resolve to
https://example.com/java/Dockerfile

What if in this Devfile I want to refer to a file Dockerfile that is in my repo (git://github.com/kadel/example/Dockerfile) Would it be just ./Dockerfile or should we introduce something more explicit like `${DEVFILE_ROOT}?

[groeges]

@kadel In your post above, was this:

In the context of this devfile, ${PARENT_ROOT}/Dockerfile would resolve to
https://example.com/java/Devfile

supposed to be:

In the context of this devfile, ${PARENT_ROOT}/Dockerfile would resolve to
https://example.com/java/Dockerfile

referencing the Dockerfile in the URL and not Devfile?

[kadel]

@kadel In your post above, was this:

In the context of this devfile, ${PARENT_ROOT}/Dockerfile would resolve to
https://example.com/java/Devfile

supposed to be:

In the context of this devfile, ${PARENT_ROOT}/Dockerfile would resolve to
https://example.com/java/Dockerfile

referencing the Dockerfile in the URL and not Devfile?

oh, yes. That should be Dockerfile. My bad. Fixed.

[neeraj-laad]

I have been thinking of this as well for a slightly different but related use case. A stack may also provide part of the application code as added value.

When we are defining commands/containers in a devfile, we can use $PROJECTS_ROOT as the location where the user's application code is made available in my container using mountSources: true definition.

However, there is no to express this for files that we need from the stack (parent devfile). Current alternatives are:

• create a custom container image with added files
• add a step to do git clone as part of initializing the container

Both these approach can work but cause additional overhead for stack maintainer. Moreover, if the build/deploy guidance will be coming from the stack then I feel almost every stack will need this. Why not make it simpler to access these files?

It would be good to have all files from the stack (devfile's location or explicitly declared in the devfile) made available as a volume mount in the container at location $STACK_ROOT.

If we did not want this done implicitly then we can use a flag like mountStack:true (or a similar name) to trigger this.

[deboer-tim]

I agree we want to make this simple for stack maintainers, but I think it's overloading this issue to cover both. Can we keep this issue focussed on what default variables there should be and how/where you can use them, and open another issue for mounting the stack into the container?

[l0rd]

This issue is related to the way we distribute devfiles. Parents will most likely be stored and distributed using a devfile registry. This is how I can reference a java stack from a devfile:

parent:
  id: mycompany/java-stack/11

That is important because ${STACK_ROOT}/Dockerfile doesn't make much sense if the parent is distributed using a devfile registry. Even if we publish the Dockerfile on the same registry in mycompany/java-stack/11/Dockerfile we should then agree on a mechanism to retrieve those files and inject them in a workspace.

I would propose to distribute those files a zip files in a devfile registry (or as an OCI artifact if we use OCI registry as a devfile backend). That artifact (zip file) should be referenced in the devfile as context:

context: mycompany/java-stack/11

The context would be pulled and unzipped in ${CONTEXT_ROOT} (default is /context/) as a preStart event.

Devfiles inherits their parents context unless this get overridden.

[scottkurz]

Seems there's some overlap with the more recent: #457

[elsony]

Community call discussion 3/28:

1. When a stack is being used, it should download the files in the stack in a given registry and put them under the local source folder.
2. Devfile library has functions to download the devfiles. The behaviour should go to each parent and download the files from the parent tree.
3. In case of the file conflict caused by the same file exists in both child and parent, the files in the child devfiles will be used.
4. This behaviour should also be documented in the specification on how to handle supporting files that comes with the parent.
5. Given that the supporting files will be downloaded, we will not introduce the ${STACK_ROOT} variable.
6. This item is still targeted as part of the devfile 2.2 release