Learn about how to structure a test runner image for the CodeCrafters test runner
[build]
.CODECRAFTERS_DEPENDENCY_FILE_PATHS
have changed, triggers a re-build of the test runner image (i.e. back to step 1)/app-cached
to $CODECRAFTERS_SUBMISSION_DIR
if present.CODECRAFTERS_SUBMISSION_DIR
to /app
/app/.codecrafters/compile.sh
if it exists.
[compile]
.CODECRAFTERS_TEST_CASES_JSON
based on the current test run./app/.codecrafters/run.sh
.CODECRAFTERS_DEPENDENCY_FILE_PATHS
environment variable in the image. It will only re-build the image if the files listed in the variable change.
A Dockerfile can contain steps to install dependencies, like cargo install
for Rust, and npm install
for JavaScript.
Since files like Cargo.toml
& package.json
don’t change often, this helps avoid re-installing dependencies on every run.
Any Dockerfile steps that emit output will be printed to the user’s test run logs with the [build]
prefix.
[build] logs
[build]
logs, you can add > /dev/null
to the end of the command.CODECRAFTERS_DEPENDENCY_FILE_PATHS
environment variable is not present, the test runner will never re-build the image./.codecrafters/compile.sh
, it will be run once before invoking the tester.
This is useful with compiled languages like Rust, where the first compilation can take a long time, but running the compiled binary is fast.
Logs from this script will be printed to the user’s test run logs with the [compile]
prefix.
[compile] logs
/app-cached
, they will be copied to /app
folder (overwriting any of the user’s code) before running the tester.
This can be used to store files required for incremental compilation in languages that support it.