Support easier access to files from the stack

[neeraj-laad]

An application stack (represented by a devfile) might need to provide additional files to support certain use cases. Some examples that come to mind are:

• Dockerfile for converting app into a container image
• shell scripts for supporting commands for iterative development
• source code providing some value add for enriching the application.

Today, we can use $PROJECTS_ROOT as the location where the user's application code is made available in my container using mountSources: true definition on a component/container.

However, there is no way to express this for files that we need are not coming form user's application:

• files from component's Devfile
• files from parent Devfile

The current options 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. I feel almost every stack will need this capability and it will be a big improvement in the experience if we can simplify access to stack code.

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.

We can use the mountSources: true flag or create a new one mountStack:true (or a similar name) to trigger this.

[neeraj-laad]

This is related to #46

[sbose78]

Got it, as a example, if a stack looks like

nodejs-postgres
  devfile.yaml
  build/
       Dockerfile
  manifests/
       deploy.yaml

Then, our tools could make a mount path available
/var/data/stack/ which would contain:

• /var/data/stack/build/Dockerfile
• /var/data/stack/manifests/deploy.yaml

This is aligned with my initial thoughts around how tools would implement STACK_ROOT

[sbose78]

Updated description in #46 to associate this as a related implementation.

[neeraj-laad]

Yes this is very similar.. but I'm considering where there are .js files in that stack too.

nodejs-express
  devfile.yaml
  src/
       package.json
       server.js
  build/
       Dockerfile
  manifests/
       deploy.yaml

The package.json, and server.js from the stack can then combine with user's app during iterative development and also during the final image build.

[sbose78]

Got it.
Yeah, it could be any type of files!

[groeges]

@sbose78 @neeraj-laad If we have a devfile that has a reference to a parent devfile, as per #25, this uses a uri to point to the parent devfile, https://raw.githubusercontent.com/eclipse/che-devfile-registry/master/devfiles/nodejs/devfile.yaml as can be seen in the snippet of this devfile.

schemaVersion: 2.0.0
metadata:
  name: nodejs-app
parent:
    uri: https://(...)/nodejs/devfile.yaml

If the additional files are within the same location as the parent devfile, then having just a uri to reference the parent devfile doesn't make it easy to obtain all the additional files.

We may need a different option to specify how/where to obtain the parent devfile and its associated files, possibly in a similar manner to that used to specify the git repo for projects. For example:

schemaVersion: 2.0.0
metadata:
  name: nodejs-app
parent:
    type: git
    location: https://github.com/eclipse/che-devfile-registry.git
    sparseCheckoutDir: /devfiles/nodejs

This would allow for the mount path /var/data/stack/ to be more easily populated.

Thoughts?

[l0rd]

One way to address this problem would be using a preStart event defined in the parent devfile.

The main question here is how to distribute the files to be copied (Dockerfiles, scripts etc...). And my would be using an OCI registry artifact. That can be an image (FROM scratch) that only contains the files to be copied or a custom OCI artifact (the latter is interesting in the scenario where the devfile registry is an OCI registry).

[elsony]

Removing from 2.2 specs since this item seems to be an old item that does not need to be part of 2.2 specs.

[github-actions]

This issue is stale because it has been open for 90 days with no activity. Remove stale label or comment or this will be closed in 60 days.