Skip to main content
Each task takes a task_config parameter which is used to define the config like resource the task execution will require, the python version, libraries, apt packages, cuda version, etc. for the task.

Things you can define in task config

  • env: you can pass the environment variables as env in task config, where env is a dictionary of key-value pairs.
  • service_account: you can pass the service_account name in the task config which is necessary to save the input and output data of the task.
  • resources: You can define the resource to allocate to each of the tasks, where you can define the cpu limit, storage limit, memory limit, GPU types, etc. You can refer to this article for more information on each.
  • mounts: You can attach volume mounts such as volume mounts, string mounts or secret mounts. You can learn more about mounts and how to use them in workflow in this guide.

Types of task config

  • There are two types of task config PythonTaskConfig and ContainerTaskConfig.
    • PythonTaskConfig: This task config can be passed in the normal python task in the task decorator. You can define the environment variables, Resources, service account, and the image spec in PythonTaskConfig. The image spec can be of two types TaskPythonBuild and TaskDockerFileBuild.
      • TaskPythonBuild is used when you do not have a Dockerfile and you want to build an image where you want to specify the pip packages, apt packages or requirements file path in the build spec, then TaskPythonBuild is used.
      • TaskDockerFileBuild is used when you already have a Dockerfile and you just want to build then you use TaskDockerFileBuild.
    • ContainerTaskConfig: This task config can be used when you already have a docker image and you want to use that as a task in the workflow directly or you have code uploaded on GitHub or the remote source. There you have a docker file which you want to use as a task in the workflow.
    • PySparkTaskConfig: This task config is used for Spark tasks that run distributed PySpark jobs. The image spec can be of two types:
      • TaskPySparkBuild is used when you want TrueFoundry to build a Spark image with your code and dependencies. You can specify the Spark version, pip packages, apt packages, or requirements file path.
      • TaskSparkImage is used when you already have a pre-built Spark image that contains all your workflow code and dependencies. This skips the Docker build phase entirely, making deployments faster. Your image must contain:
        1. All workflow source code at /app (or appropriate PYTHONPATH)
        2. truefoundry[workflow,spark] package installed
        3. PySpark version matching the spark_version parameter
        4. Hadoop AWS/GCS/Azure JARs if using cloud storage

Building a TaskSparkImage-Compatible Image

When using TaskSparkImage, your pre-built image must contain everything needed to execute the Spark task. This is because:
  1. The Spark driver pod imports your task function - Without the code, Python cannot import the module
  2. Flytekit deserializes inputs and calls your function - The workflow runtime needs to be installed
  3. No code injection happens at deploy time - Unlike TaskPySparkBuild, the image is used as-is

Required Directory Structure

Example Dockerfile

When building for deployment to a Kubernetes cluster, ensure you build for the correct architecture:
When to use TaskSparkImage vs TaskPySparkBuild:
  • Use TaskSparkImage when you have a CI/CD pipeline that builds your Spark images, or when you want faster deployments by skipping the build phase.
  • Use TaskPySparkBuild when you want TrueFoundry to build the image for you with your code and dependencies automatically injected.