Devfile support for stacks to consume build output on local file system

[elsony]

The existing stack devfiles that are currently under our existing devfile registry https://github.com/devfile/registry (copied from the odo registry https://github.com/odo-devfiles/registry) always do the build within the build containers and then transfer the build output contents to the runtime container.

If the user starts from a local development environment, e.g. a local IDE, the IDE already set up and already building the application in the local IDE using mechanisms that are native to the IDE. When dev tools, e.g. odo, tries to build using devfiles in that scenario, the existing tool will try to build the application in the container from scratch again. This extra build step will lengthen the round-tripping time during inner-loop development.

Note that the existing devfile specification does not block stack providers to come up with a stack that skips the container build and simply transfer the local build output content to the runtime container. This item is to see if there is anything that we need on the devfile specification that will help stack providers to define a stack that can consume build output on the local file system.

There are a couple of approaches that we can take:

1. Introduce the notion of binary mode vs source mode in the devfile spec. Based on the mode, it may execute different build steps to:

   1. binary mode: transfer local build output to the runtime container. In this case, we may need to provide a way to define where the stack can find the local build output. (Note that the build output local may differ across different IDEs so we most likely need to make use of the global environment attribute support (Top level attribute definition in a devfile #239) to allow tools to provide the binary output location on the fly.
   2. source mode: transfer the source files to the build container as before and do the build in the runtime container

2. Leave implementation details on binary mode vs source mode to the contract between specific tools, e.g. odo, and the stack to provide tools specific solution. The downside for this is the stack devfile will need to do auto-detect as part of the build operation.

[elsony]

@maxandersen This is one of the main concerns on the existing devfile spec/scenario that you have brought up in the past. Feel free to add any other requirements that I haven't covered in my original description.

[elsony]

Community call discussion 3/28:

1. The current devfile specification is already flexible enough to allow that. No change is needed.
2. Sample tools like odo already supports that via custom annotation (see https://odo.dev/docs/tutorials/using-devfile-odo.dev.push.path-attribute for details).
3. Users can write a devfile with an empty build step or just copy the binary out from IDE to the container as part of the build step to achieve.
4. Users can also have different build commands to cover build within an IDE or doing the full source build.