|`spec.clustersInfo`| Determines if all (`injectAll`) or specific (`clusters`) Kubernetes cluster contexts are available for the pipeline build.<br>See[Select Kubernetes cluster contexts]({{site.baseurl}}/docs/pipelines/pipelines/#select-kubernetes-cluster-contexts).| object| Optional|

|`spec.clustersInfo.injectAll`| When set as`true` (NIMA is this the default?), injects all clusters integrated with Codefresh into the pipeline build.| boolean| Optional|

|`spec.clustersInfo.clusters`| Applicable only when`injectAll`is set to`false`.<br>One or more comma-separated names of clusters to inject during the pipeline build. For example,`aws`,`eks-prod`.| array| Optional|

|`spec.variablesSchema`| ???| string|`????'`|

|`spec.variablesSchema`| ???(NIMA: I THINK THIS CAN BE REMOVED)| string|`????'`|

|`spec.variables`| The variables defined in the pipeline. See[spec.variables](#specvariables).| array| Optional|

|`spec.specTemplate`| ???? . See[spec.specTemplate](#specspectemplate).| object| Optional|

|`spec.steps`| The steps to be executed by the pipeline, as a list of key-values pairs.(NIMA: need to add more info)<br>See[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/).| object| Required|

|`spec.services`| ???| object| Optional|

|`spec.hooks`| ??| object| Optional|

|`spec.stages`| The stages into which to group the pipeline's steps. In the pipeline's build view, each stage is displayed as a separate column.<br>Stages are only for visualization and do not affect pipeline execution.<br>See[Grouping steps into stages]({{site.baseurl}}/docs/pipelines/stages/).| array| Optional|

|`spec.mode`| The execution mode for the pipeline, and can be one of the following:{::nomarkdown}<ul><li><codeclass=highlighter-rouge>sequential</code>: The default, executes the steps in the order in which they are listed.</li><li><codeclass=highlighter-rouge>parallel</code>: Evaluates all step conditions at the same time and executes those steps that meet the requirements in parallel. Parallel execution mode allows you to order steps in ways not possible with sequential mode.</li>{:/}See[Advanced workflows for pipelines]({{site.baseurl}}/docs/pipelines/advanced-workflows/).| string| Optional|

|`spec.fail_fast`| Determines pipeline execution behavior in case of step failure. {::nomarkdown}<ul><li><codeclass="highlighter-rouge">true</code>: The default, terminates pipeline execution upon step failure. The Build status returns <codeclass="highlighter-rouge">Failed to execute</code>.</li><li><codeclass="highlighter-rouge">false</code>: Continues pipeline execution upon step failure. The Build status returns <codeclass="highlighter-rouge">Build completed successfully</code>. <br>To change the Build status, set <codeclass="highlighter-rouge">spec.strict_fail_fast</code> to <codeclass="highlighter-rouge">true</code>.</li></ul>{:/}| boolean| Optional|

| `spec.strict_fail_fast` | Specifies how to report the Build status when `fail_fast` is set to `false`.<br>**NOTE**:<br>Requires Runner chart v6.3.9 or higher.<br><br>You can set the Build status reporting behavior at the root-level or at the step-level for the pipeline.{::nomarkdown}<ul><li><code class="highlighter-rouge">true</code>:<ul><li>When set at the <i>root-level</i>, returns a Build status of failed when any step in the pipeline with <code class="highlighter-rouge">fail_fast=false</code> fails to execute.</li><li>When set at the <i>step-level</i>, returns a Build status of failed when any step in the pipeline with <code class="highlighter-rouge">fail_fast=false</code> and <code class="highlighter-rouge">strict_fail_fast=true</code> fails to execute.</li></ul></li><li><code class="highlighter-rouge">false</code>:<ul><li>When set at the <i>root-level</i>, returns a Build status of successful when any step in the pipeline with <code class="highlighter-rouge">fail_fast=false</code> fails to execute.</li><li>When set at the <i>step-level</i>, returns a Build status of successful when any step in the pipeline with <code class="highlighter-rouge">fail_fast=false</code> fails to execute.</li></ul></li></ul>{:/}<br>**NOTES**:<br>`strict_fail_fast` does not impact the Build status reported for parallel steps with `fail_fast` enabled. Even if a child step fails, the parallel step itself is considered successful. See also [Handling error conditions in a pipeline]({{site.baseurl}}/docs/pipelines/advanced-workflows/#handling-error-conditions-in-a-pipeline). | ??? | Optional |

|`spec.success_criteria`| ?????| string|`????'`|

|`spec.options`| Advanced options controlling pipeline execution behavior.(NIMA: what happens when not defined? takes the default for each option?)<br>See[spec.options](#specoptions).| optionsSchema???| Optional|

|`spec.steps`|(**NIMA: THIS IS AUTOGENERATED**)The steps to be executed by the pipeline, as a list of key-values pairs.(NIMA: need to add more info)<br>See[Steps in pipelines]({{site.baseurl}}/docs/pipelines/steps/).| object| Required|

|`spec.services`| ???(**NIMA: THIS IS AUTOGENERATED**)| object| Optional|

|`spec.hooks`| ??(**NIMA: THIS IS AUTOGENERATED**)| object| Optional|

|`spec.stages`|(**NIMA: THIS IS AUTOGENERATED**)The stages into which to group the pipeline's steps. In the pipeline's build view, each stage is displayed as a separate column.<br>Stages are only for visualization and do not affect pipeline execution.<br>See[Grouping steps into stages]({{site.baseurl}}/docs/pipelines/stages/).| array| Optional|

|`spec.mode`|(**NIMA: THIS IS AUTOGENERATED**)The execution mode for the pipeline, and can be one of the following:{::nomarkdown}<ul><li><codeclass=highlighter-rouge>sequential</code>: The default, executes the steps in the order in which they are listed.</li><li><codeclass=highlighter-rouge>parallel</code>: Evaluates all step conditions at the same time and executes those steps that meet the requirements in parallel. Parallel execution mode allows you to order steps in ways not possible with sequential mode.</li>{:/}See[Advanced workflows for pipelines]({{site.baseurl}}/docs/pipelines/advanced-workflows/).| string| Optional|

|`spec.fail_fast`|(**NIMA: THIS IS AUTOGENERATED**)Determines pipeline execution behavior in case of step failure. {::nomarkdown}<ul><li><codeclass="highlighter-rouge">true</code>: The default, terminates pipeline execution upon step failure. The Build status returns <codeclass="highlighter-rouge">Failed to execute</code>.</li><li><codeclass="highlighter-rouge">false</code>: Continues pipeline execution upon step failure. The Build status returns <codeclass="highlighter-rouge">Build completed successfully</code>. <br>To change the Build status, set <codeclass="highlighter-rouge">spec.strict_fail_fast</code> to <codeclass="highlighter-rouge">true</code>.</li></ul>{:/}| boolean| Optional|

| `spec.strict_fail_fast` | (**NIMA: THIS IS AUTOGENERATED**) Specifies how to report the Build status when `fail_fast` is set to `false`.<br>**NOTE**:<br>Requires Runner chart v6.3.9 or higher.<br><br>You can set the Build status reporting behavior at the root-level or at the step-level for the pipeline.{::nomarkdown}<ul><li><code class="highlighter-rouge">true</code>:<ul><li>When set at the <i>root-level</i>, returns a Build status of failed when any step in the pipeline with <code class="highlighter-rouge">fail_fast=false</code> fails to execute.</li><li>When set at the <i>step-level</i>, returns a Build status of failed when any step in the pipeline with <code class="highlighter-rouge">fail_fast=false</code> and <code class="highlighter-rouge">strict_fail_fast=true</code> fails to execute.</li></ul></li><li><code class="highlighter-rouge">false</code>:<ul><li>When set at the <i>root-level</i>, returns a Build status of successful when any step in the pipeline with <code class="highlighter-rouge">fail_fast=false</code> fails to execute.</li><li>When set at the <i>step-level</i>, returns a Build status of successful when any step in the pipeline with <code class="highlighter-rouge">fail_fast=false</code> fails to execute.</li></ul></li></ul>{:/}<br>**NOTES**:<br>`strict_fail_fast` does not impact the Build status reported for parallel steps with `fail_fast` enabled. Even if a child step fails, the parallel step itself is considered successful. See also [Handling error conditions in a pipeline]({{site.baseurl}}/docs/pipelines/advanced-workflows/#handling-error-conditions-in-a-pipeline). | ??? | Optional |

|`spec.success_criteria`| ?????(**NIMA: NOT SURE WHAT THIS IS - MAYBE AUTOGENERATED**)| string|`????'`|

|`spec.options`| Advanced options controlling pipeline execution behavior.(NIMA: what happens when not defined? takes the default for each option? (**NIMA: WILL TAKE THE DEFAULTS FOR EACH OPTION WHEN NOT DEFINED**))<br>See[spec.options](#specoptions).| optionsSchema???| Optional|

|`spec.concurrency`| The maximum number of builds that can run simultaneously for the pipeline, and can range from`0` (the default), to`14`, or`unlimited`.<br>A concurrency of`0` freezes execution of the pipeline, switching it to maintenance mode.<br>. Useful when your pipeline has only one trigger.| integer| Optional|

|`spec.triggerConcurrency`| The maximum number of concurrent builds than can run_per trigger defined for the pipeline_.<br>Can range from`1` (the default), to`15`, or`unlimited`.<br>Useful when your pipeline has multiple triggers.| integer| Optional|

|`spec.branchConcurrency`| The maximum number of concurrent builds than can run_per branch defined for the pipeline_.<br>Can range from`1` (the default), to`15`, or`unlimited`.<br>Useful when your pipeline builds different branches.| integer| Optional|

|`spec.priority`| ???| string|`????'`|

|`spec.terminationPolicy`| Determines how and when the pipeline build should terminate. See[spec.terminationPolicy](#specterminationpolicy)| ???| ??|

|`spec.externalResources`| The external files, such as scripts or other resources available to the pipeline.<br>When defined, they are automatically retrieved and available when the pipeline starts execution.<br>See[spec.externalResources](#specexternalresources).| array| Optional|

|`spec.debug`| ????| string| Optional??|

|`spec.debug`| ????(**NIMA: THIS IS AUTOGENERATED WHEN USERS START USING DEBUG IN THE UI - CAN BE DEFINED HERE IF USERS WANTS**)| string| Optional??|

|`spec.serviceAccount`| ???The service account to use for authentication in ECR integrations for this pipeline.| string| Optional|

See[External resources]({{site.baseurl}}/docs/pipelines/pipelines/#external-resources).