DIAL App Builder Python
DIAL App Builder Python prepares Code App sources for a container image build. It downloads a project from DIAL file storage, validates its entrypoint and requirements, and supplies a Dockerfile template. This reference covers 0.1.0 for platform engineers configuring the App Controller build pipeline.
Role in Code Apps
The builder is a command-line process, not a persistent HTTP service or the DIAL Chat application editor. It runs as the preparation init container in an App Controller build Job. A separate image-builder container, Kaniko by default, builds and pushes the application image.
| Stage | Component | Output |
|---|---|---|
| Author | DIAL Chat and DIAL Core | A project folder in DIAL file storage |
| Prepare | App Builder Python | Downloaded, validated sources and a selected Dockerfile template |
| Build | Kaniko or a compatible configured image builder | An application image in a registry |
| Run | App Controller and Knative | A service that runs the Code App |
The two build containers and their shared mounts are defined in App Controller's application.yaml. Source authors use the Code Apps guides; they do not deploy the builder directly.
Processing
- Copy the template. The image entrypoint copies
templates/$PROFILE/*intoTEMPLATES_DIR. - Read the source folder. The Python process requests recursive metadata from Core and follows pagination tokens.
- Download files. Each file is downloaded through Core's file API into
TARGET_DIR, preserving its relative path. - Validate the project. For the bundled
python-pipprofile,app.pymust exist and requirements must pass the package allowlist. - Exit. A successful preparation allows the Job's image-building container to proceed. Preparation failures stop the init container.
Sources: entrypoint, downloads and pagination, and validation.
Project and runtime contract
The python-pip profile expects a project with this structure:
sources/
├── app.py
├── requirements.txt
└── other application files
app.py is mandatory. A missing requirements.txt is created as an empty file during validation. The generated runtime starts Uvicorn with app:app, so the module must expose an ASGI application named app. Existence of that object is not checked by the builder.
The Dockerfile template takes BASE_IMAGE from the controller's runtime configuration. It installs Uvicorn 0.31.0 and the project's requirements, copies the sources, and runs as UID 1001 on port 8080. The project declares any SDK or application dependencies it needs in requirements.txt.
Dependencies and deployment
| Dependency | Purpose |
|---|---|
| DIAL Core file and metadata APIs | Lists and downloads the source project |
| DIAL credentials | Supply access to the source folder, normally through the build Secret created by App Controller |
| Writable source and template directories | Share prepared files with the image-builder container |
| App Controller | Supplies the source folder, profile, DIAL URL, and package allowlist |
| Image builder and registry | Consume the output; the Python preparation process does not build or push the final image itself |
The published preparation image is epam/ai-dial-app-builder-python:0.1.0. Its Dockerfile uses Python 3.11, runs as UID 1001, and prepares writable /sources and /templates directories. It exposes no HTTP port or health endpoint.
The DIAL 1.38 to 1.48 platform releases pin 0.1.0.
The builder's Python version is separate from the generated application's BASE_IMAGE. Controller runtime selection determines the latter; see Build and runtime selection.
Warning
The allowlist validates requirement names; it does not isolate running application code or its network access. Kubernetes workload permissions, egress rules, filesystem access, and resource limits remain deployment responsibilities.