(That’s right, we’re using the very tool we will later be installing!) You should see something akin to the following:
. ├── bin │ ├── detect <- similar to a buildpack ./bin/detect │ ├── generate <- similar to a buildpack ./bin/build ├── extension.toml <- similar to a buildpack buildpack.toml
extension.tomldescribes the extension, containing information such as its name, ID, and version, as well as the buildpack API that it implements. Though extensions are not buildpacks, they are expected to conform to the buildpack API except where noted. Consult the spec for further details.
./bin/detectis invoked during the
detectphase. It analyzes application source code to determine if the extension is needed and contributes build plan entries (much like a buildpack
./bin/detect). Just like for buildpacks, a
./bin/detectthat exits with code
0is considered to have passed detection, and fails otherwise.
./bin/generateis invoked during the
generatephase (a new lifecycle phase that happens after
detect). It outputs either or both of
run.Dockerfilefor extending the builder or run image, respectively.
run.Dockerfileinstructions are limited to a single
FROMinstruction (effectively, it is only possible to switch the run-time base image to a pre-created image i.e., no dynamic image modification is allowed). Consult the spec for further details.
We’ll take a closer look at the executables for the
tree extension in the next step.