combine building application and bundle steps

[sbawaska]

I am trying to build a bundle that will have a go binary as the run tool. The repo has the following structure:

.
|____cnab
|    |____app
|    |    |____run
|    |____Dockerfile
|____duffle.json
|____pkg
|____ ...
|____main.go
|____Makefile
...

I would like to build the go binary and package it when the bundle gets built. However, I cannot access my source code from the Dockerfile since it is outside the build context.

It would be nice if building the application and building the bundle can be combined into a single step.

[carolynvs]

I tried this out too and couldn't figure out how to work with files at the root of my repo when the duffle config file is also at the root of the repo. Duffle seems to require that I put anything that I'm working with into the cnab subdirectory and I couldn't find a way to make this scenario work.

Is it a hard design requirement that I separate building my application from building the bundle? I'm wondering if the Duffle way would be to separate this into separate directories, one for the bundle, and one for the application, build the application first, then copy the binary into the bundle. Or another option being to again separate them, but before running duffle build, copy the code directory into cnab?

It would be great if Duffle could support having the docker context at the root level, instead of in the subdirectory instead.

[technosophos]

The original design was that Duffle was only concerned with assembling a package, not building artifacts that might be placed into the package. But if we could make a pretty trivial change and support that behavior, I wouldn't be opposed.

[radu-matei]

Early prototypes of Duffle used to build all image components, as well as the invocation images and the bundle itself.

But since the goal for Duffle's building tools at this point is to exhibit how the artifacts in the spec are meaningfully used to build a bundle, (see #752), I think we should leave this task to higher level tooling.

That being said, I'm happy to discuss around how the higher level tool should work.

[jeremyrickard]

@radu-matei I think we should close this and perhaps have some appropriate documentation that highlights this?