<commit_before># dockerfile

Build Dockerfiles with Puppet.


## Design
Dockerfile syntax is implementation specific, and a prime candidate to be abstracted by Puppet's DSL.
This module provides a Puppet function which takes a lambda containing Puppet resource declarations, and returns the compiled Dockerfile's contents as a string.
By following this design, anyone who understands the Puppet language can build Docker images without an understanding of Dockerfile syntax.


## Providers
Each resource type declared within the Dockerfile must have a Docker-specific resource provider appropriate for the parent image's distribution.
The `parent_image` resource type is provided to set the parent image's name, and its osfamily for this purpose.

The provider name is prefixed with `docker_`, and suffixed with the value of `parent_image`'s osfamily attribute, i.e. `docker_el`.

Each provider should respond to the `build_script` method, which will be invoked by the dockerfile function during resource evaluation, and provided with a visitor context object.
It is expected that each provider's `build_script` method will return a string to be included in a Dockerfile `CMD` directive.
The command doesn't need to be idempotent since it will only ever be invoked during the container build process.


## Examples
TODO


## TODO
* Providers for built-in resource types (file, user, service, etc.)
* Traverse dependency graph instead of including resources in evaluation order
* Types for misc. Dockerfile directives (env, expose, etc.)
* Make each Dockerfile directive "safe" (i.e. escape where necessary)
* Examples in README
* Acceptance tests (with Docker in Travis)


## Contributing
* Find a TODO or bug
* Fork/branch/commit/PR
* Integration test coverage is important for the function itself (since it's coupled to the Puppet parser)
* Unit tests are fine for types/providers<commit_msg>Remove TODOs<commit_after># dockerfile

Build Dockerfiles with Puppet.


## Design
Dockerfile syntax is implementation specific, and a prime candidate to be abstracted by Puppet's DSL.
This module provides a Puppet function which takes a lambda containing Puppet resource declarations, and returns the compiled Dockerfile's contents as a string.
By following this design, anyone who understands the Puppet language can build Docker images without an understanding of Dockerfile syntax.


## Providers
Each resource type declared within the Dockerfile must have a Docker-specific resource provider appropriate for the parent image's distribution.
The `parent_image` resource type is provided to set the parent image's name, and its osfamily for this purpose.

The provider name is prefixed with `docker_`, and suffixed with the value of `parent_image`'s osfamily attribute, i.e. `docker_el`.

Each provider should respond to the `build_script` method, which will be invoked by the dockerfile function during resource evaluation, and provided with a visitor context object.
It is expected that each provider's `build_script` method will return a string to be included in a Dockerfile `CMD` directive.
The command doesn't need to be idempotent since it will only ever be invoked during the container build process.


## Examples
TODO


## Contributing
* Find a TODO or bug
* Fork/branch/commit/PR
* Integration test coverage is important for the function itself (since it's coupled to the Puppet parser)
* Unit tests are fine for types/providers
{'fraction_non_alphanumeric': 0.046274738067520374, 'fraction_numerical': 0.0, 'mean_word_length': 5.061728395061729, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6008706', 'n_tokens_mistral': 867, 'n_tokens_neox': 810, 'n_words': 480}