taskOptions is an array of options that enable customizing any or all task pods. Multiple option sets can be created to customize each individual task. Some options are simply added to the pod spec intuitively. Others are used by the pod indirectly, like the pod’s ServiceAccount Role Policy. Finally there are options that change the task’s execution script.
taskOptions: - for: ["init", "plan", "apply", "init-delete", "plan-delete", "apply-delete"] script: source: https://example.com/path/to/terraform-executor.sh
taskOptions apply to the tasks called out in the
for: array. So for each of the tasks, the
source, which is the task’s run script, is modified to use
taskOptions: - for: ["preinit"] annotations: foo: bar script: source: https://example.com/my/preinit.sh - for: ["plan"] env: - name: TF_LOG value: DEBUG
This configuration sets the preinit task to execute the script from
https://example.com/my/preinit.sh and also adds an annotation to the preinit pod
foo=bar. A second configuration adds the environment variable
TFO_LOG=DEBUG to the plan pod.
Task Option Configuration Reference
When defining task options the user selects which tasks by name to apply the options too. This is done in the
Task selection option
|A list of tasks that will accept the options.|
These options are directly related with the Kubernetes Pod definition:
|Key/value annotations that get added to the task pods's metadata annotations.|
|Key/value lablels that get added to the task pod's metadata labels.|
|Environment variables, defined like the pod's container EnvVar, that are added to the task pod's main container.|
|Environment variables that get injected from a ConfigMap or Secret source. This is defined like a pod container's EnvFromSource.|
|Resource requests and limits for the pod. See Resource Requirements.|
When the task needs more permissions, the following rbac options can be set to configure rbac:
|RBAC Role rules that will be added to all runner pods. (This option actually affects all tasks because they all currently share a ServiceAccount. Making a unique service account per task is a TODO item at the moment.)|
Task Execution Options
The main purpose of a task is to execute a script. There are several ways to change the task’s default execution. Only one of the three will be used. The order of precedence is:
|Define the script directly in the yaml.|
|Select an existing ConfigMap name and data key that has the script as the value.|
|An https endpoint that has the script to execute. Example: hello-world.sh|
Plugins are actually (unmonitored) tasks and accept
taskOptions like any other task.
For example, given a plugin like the following:
plugins: monitor: image: "ghcr.io/galleybytes/monitor:latest" imagePullPolicy: "IfNotPresent" when: "After" task: "setup"
the plugin is assigned the “monitor” task name. So the plugin pod can be defined further with
taskOptions: - for: - "monitor" env: - name: CLUSTER_NAME value: "kind-kind" - name: DBHOST value: "database" - name: PGPASSWORD value: "pass" - name: PGUSER value: "pg" - name: PGDATABASE value: "crud" - name: PGPORT value: "5432" - name: ENV value: "devlocal"