Adjusting timeouts and resources

When a Release Pipeline is executed through a PipelineRun, the Pipeline will run until a timeout is reached. This timeout is usually an hour and will make the Release Pipeline fail if it doesn’t finish on time.

To overcome this, there are two strategies Konflux users can follow.

Adjust timeouts

Whenever a pipeline is defined through the tenantPipeline/finalPipeline fields in the ReleasePlan or the pipeline field in the ReleasePlanAdmission, users can specify a timeouts field in the following way:

pipeline:
  pipelineRef:
    resolver: git
    params:
      - name: url
        value: "<url-to-repo>.git"
      - name: revision
        value: main
      - name: pathInRepo
        value: "<path-to-your-pipeline>"
  timeouts:
    pipeline: "2h0m0s" (1)
    tasks: "1h0m0s" (2)
    finally: "1h0m0s" (3)
yaml
1 specifies the timeout for the entire PipelineRun. Defaults to the global configurable default timeout of 60 minutes.
2 specifies the timeout for the cumulative time taken by non-finally Tasks specified in the Pipeline.
3 timeout for the cumulative time taken by finally Tasks.
Tekton enforces a restriction on the pipeline timeout—it must be greater than or equal to the sum of the timeouts for tasks and finally.

Adjust resources

Release Pipelines are configured with default CPU and memory values for each Task and Step. These defaults are based on testing with typical workloads and are refined over time using user feedback. However, some Releases contain a larger than average number of Components, which can cause certain Tasks or Steps to exceed the default resources and fail, often due to OOMKilled errors.

Increasing resources globally for every user would waste cluster resources, so Konflux supports per Release resource overrides using taskRunSpecs.

Konflux is exploring future improvements to make resource allocation more dynamic, for example by tuning defaults based on the number of Components.

Understand taskRunSpecs

taskRunSpecs allow you to override compute resources at runtime for a specific Task or Step without modifying the underlying Pipeline or Task definitions. They are defined in the pipeline section of a ReleasePlanAdmission and apply to any Release execution that uses the ReleasePlanAdmission.

Use taskRunSpecs when:

  • A Task fails with OOMKilled errors

  • The Release has an unusually large number of Components

Task-level vs Step-level overrides

There are two override mechanisms available:

Task-level override

  • Applies the same compute resources to all Steps in a Task

  • Overrides any defaults defined in the Task

  • Can waste cluster resources if the Task has many steps and only one Step is resource-heavy

  • Applies compute resources to one specific step only

  • Other steps keep their default compute resources

  • Minimizes cluster resource usage to the failing Step only

Find the Pipeline, Task, and Step names

To adjust resources for a Task or Step, you need to identify the following names:

  • pipelineTaskName - The Task name as defined in the Pipeline

  • stepName - The Step name inside the Task (required for step-level overrides only)

Identify the Pipeline

Inspect the pipeline object in your ReleasePlanAdmission:

pipeline:
  pipelineRef:
    resolver: git
    params:
      - name: url (1)
        value: "<url-to-repo>.git"
      - name: revision (2)
        value: <revision>
      - name: pathInRepo (3)
        value: "<path-to-your-pipeline>"
yaml
1 The URL to the repository containing the Pipeline.
2 The branch of the repository containing the Pipeline.
3 The path to the Pipeline within the repository.
Using the pathInRepo value, you can locate the Pipeline definition in the repository. All managed Releases use pipelines stored in the release-service-catalog repository.

Find the pipelineTaskName

Open the Pipeline definition in the repository on the specified branch at the pathInRepo location and inspect the tasks section.

tasks:
  - name: <task-name> (1)
    taskRef:
      resolver: "git"
      params:
        - name: url
          value: "<url-to-repo>.git"
        - name: revision
          value: <revision>
        - name: pathInRepo
          value: "<path-to-your-task>"
yaml
1 The name of the Task as defined in the Pipeline. This value is the pipelineTaskName you’ll use in taskRunSpecs.

Find the stepName (for step-level overrides)

Open the Task definition in the repository on the specified branch using the pathInRepo value in the taskRef from the Pipeline definition.

steps:
  - name: use-trusted-artifact (1)
    image: <image-name>
  - name: create-release-from-binaries
    image: <image-name>
  - name: create-trusted-artifact
    image: <image-name>
yaml
1 This value is the stepName you’ll use in stepSpecs.
The task definition is typically stored in the same repository as the Pipeline, but it can also be stored in a different repository.

Configure resource overrides

Task-level override example

The following example shows a ReleasePlanAdmission with a task-level resource override. All Steps in the verify-conforma Task will receive these resources.

apiVersion: appstudio.redhat.com/v1alpha1
kind: ReleasePlanAdmission
metadata:
  labels:
    release.appstudio.openshift.io/block-releases: 'false'
  name: release-production
  namespace: <managed-tenant-namespace>
spec:
  applications:
    - demo-app
  data: <key>
  origin: <dev-tenant-namespace>
  pipeline:
    pipelineRef:
      resolver: git
      params:
        - name: url
          value: "<url-to-repo>.git"
        - name: revision
          value: <revision>
        - name: pathInRepo
          value: "<path-to-your-pipeline>"
    serviceAccountName: release-service-account
    taskRunSpecs:
      - pipelineTaskName: verify-conforma (1)
        computeResources: (2)
          limits:
            cpu: "500m"
            memory: "3Gi"
          requests:
            cpu: "250m"
            memory: "2Gi"
  policy: <policy>
yaml
1 The name of the Task as defined in the Pipeline.
2 Compute resources applied to all Steps in this Task.

The following example shows a ReleasePlanAdmission with a step-level resource override. Only the validate Step in the verify-conforma Task will receive the override resources. Other Steps will keep their default compute resources.

apiVersion: appstudio.redhat.com/v1alpha1
kind: ReleasePlanAdmission
metadata:
  labels:
    release.appstudio.openshift.io/block-releases: 'false'
  name: release-production
  namespace: <managed-tenant-namespace>
spec:
  applications:
    - demo-app
  data: <key>
  origin: <dev-tenant-namespace>
  pipeline:
    pipelineRef:
      resolver: git
      params:
        - name: url
          value: "<url-to-repo>.git"
        - name: revision
          value: <revision>
        - name: pathInRepo
          value: "<path-to-your-pipeline>"
    serviceAccountName: release-service-account
    taskRunSpecs:
      - pipelineTaskName: verify-conforma (1)
        stepSpecs:
          - name: validate (2)
            computeResources: (3)
              limits:
                cpu: "500m"
                memory: "3Gi"
              requests:
                cpu: "250m"
                memory: "2Gi"
  policy: <policy>
yaml
1 The name of the Task as defined in the Pipeline.
2 The name of the Step as defined in the Task.
3 The compute resources to apply to this specific Step.