dockerFile contents vs dockerFile...file


I’d like to understand why the dockerFile hint/requirement refers to the contents of a file vs the file itself.


This is basically a mistake. When it was added we didn’t think through all the ways one would want to use it. It way it ought to work is to allow a File object referring to the Dockerfile that can have secondaryFiles, then it would stage the Dockerfile to a directory like it does now and build the docker image from there, but you would also be able to copy things into the image.

However, if you don’t need to copy things into the image, you can use the $include construct, e.g.

  dockerFile: {$include: "MyDockerfile"}

The $include loads text inline in a preprocessing step.

Thanks for the reminder @qwofford, I’ve suggested that the fix @tetron mentioned be implemented for the next release of CWL: (this is no guarantee, however)

Thanks for bumping this issue. I am working on a workflow management system for HPC, and we have many non-trivial Dockerfiles that would benefit from referencing a file object rather than Dockerfile contents. I’m implementing the build stage of the workflow system, and while we are trying to keep it CWL-compliant, this issue complicates my work. Any Dockerfile that is longer than a few lines becomes cumbersome.

Here is an example of a Dockerfile and associated repository that I would like to support:

I would really like to see either the dockerFile spec description change to reference a file object, or see the spec name change from dockerFile to dockerFileContents. I’m happy to discuss further or provide more examples that would benefit from this change to the specification language.

1 Like