A BuildKit frontend that renders your
Dockerfile as a Twig template before building it.
It lets a Dockerfile extend another one and override only the parts that differ, instead of copy-pasting a whole file to change three lines:
# syntax=ghcr.io/castor-php/twig-dockerfile:0.1
{% extends 'Dockerfile' %}
{% block builder %}
{{ parent() }}
RUN echo "custom builder step"
{% endblock %}Add the # syntax= line and Docker pulls the frontend and uses it to build the
image — nothing to install locally.
{% extends %}/{% block %}/{% include %}between Dockerfiles- Build arguments exposed as Twig variables
copy()renders a file through Twig before adding it to the image- Additional build contexts as template sources
- Heredocs preserved, with a configurable marker when the rendered content contains one
Reference the frontend from the first line of your Dockerfile:
# syntax=ghcr.io/castor-php/twig-dockerfile:0.1Pin a MAJOR.MINOR tag rather than latest: the frontend runs inside your
builds, so an unpinned reference means a change here can change your builds
without you doing anything.
You can also override the frontend for a single build, which is handy to test a local build of it:
docker build --build-arg BUILDKIT_SYNTAX=twig-dockerfile:local .Images are published to ghcr.io/castor-php/twig-dockerfile:
| Tag | Meaning |
|---|---|
0.1.0 |
An exact release |
0.1 |
Latest patch of that minor — what you should pin |
latest |
Built from main on every push, no stability promise |
While the project is in 0.x, the minor is the breaking-change axis, so 0.1
is the safe floating tag. From 1.0 on, a 1 tag is published too.
The frontend is a Go binary that shells out to a PHP renderer, both baked into the image.
composer install
# Unit tests of the PHP renderer
vendor/bin/phpunit --testsuite transform
# Full build through a real BuildKit frontend (builds the image first)
RUN_E2E=1 vendor/bin/phpunit --testsuite e2eThe Castor Docker plugin builds its PHP and ClickHouse images with it.
MIT.