0

I have a pipeline that references a task:

---
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: foo
spec:
  tasks:
    - name: my-bar-task
      taskRef:
        name: bar-task
        bundle: ...

That task has resources:

---
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: bar-task
spec:
  steps:
    - name: step-one
      resources:
        requests:
          memory: "1Gi"
          cpu: "1"
        limits:
          memory: "2Gi"
          cpu: "1"

I would like to be able to override the resources in the pipeline definition. Something like this:

---
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: foo
spec:
  tasks:
    - name: my-bar-task
      taskRef:
        name: bar-task
        bundle: ...
        resources:
          requests:
            memory: "4Gi"
            cpu: "1"
          limits:
            memory: "5Gi"
            cpu: "1"

But when I tried that, the override was ignored. Is what I am trying possible? I know the resources can be overridden from a pipeline run but I am particularly wondering about doing that in a pipeline.

mab
  • 760
  • 4
  • 18

1 Answers1

0

At the pipeline level: NO.

However this is possible, at the PipelineRun/TaskRun level.

ALTHOUGH, this is an alpha feature (not yet globally available / "stable"). Over time, it may graduate as a stable feature -- keeping in mind there could be breaking changes in that process. Afterwards, should be enabled by default.

Nowadays, you need to enable the corresponding alpha feature first (TEP-0094: specifying resource requirements at runtime)

Depending on where/how you installed Tekton, you should have some configmap, somewhere, like the following:

$ kubectl get cm -n tekton-pipelines -o yaml feature-flags
apiVersion: v1
data:
  ...
  enable-api-fields: alpha
  ...
kind: ConfigMap
metadata:
  name: feature-flags
  namespace: tekton-pipelines

Setting enable-api-fields: alpha should enable that feature in your installation.

Having done so, you would be able to override those values, in your PipelineRun. Eg:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
spec:
  taskRunSpecs:
  - pipelineTaskName: build
    stepOverrides:
    - name: build
      resources:
        limits:
          cpu: 200m
          memory: 768Mi
        requests:
          cpu: 100m
          memory: 512Mi
  pipelineRef:
    name: docker-build

See also https://github.com/tektoncd/pipeline/issues/1530

SYN
  • 4,476
  • 1
  • 20
  • 22
  • Yes, we are able to set the resource overrides in a pipeline run successfully. But that is not the desire. In our case, there are ten or so github repos that use tekton during ci. Each of these repos runs an integration test pipeline. The resources that the integration test needs vary. We'd like to make a change in one place that affects all 10 repos. That is why I was hoping to set the resource overrides in the pipeline itself. I ended up creating a custom task exclusive to the pipeline with the needed resources so I just need to change that task. Not great reuse but satisfactory. – mab Mar 01 '23 at 14:33
  • 1
    I am accepting your answer as "no" to the question "Is what I am trying possible?" But perhaps you might edit your response to plainly state that (though it is fairly clear)? – mab Mar 01 '23 at 14:36
  • Sure. Sadly, it already took the Tekton team over 2 years to provide us with this alpha/TEP. I first asked for it in 2020, in their github repo, and I wasn't the first ... yet I do agree, this is not a satisfying answer when EventListeners are involved -- and even when creating PipelineRuns myself: this isn't easy to use, you need to know about tasks/container names within your pipelines, ... One way to ease up EL integration """might""" be to consider using triggerbindings such as "small", "large", "xlargs", then duplicate EL triggers, somehow mapping resource-hungry repos to larger sizes ... – SYN Mar 01 '23 at 22:11
  • ... yet this won't be easy, may involve additional maintenance. Maybe using repos tags/topics, which would show in payloads processed by your EL ... either way: over-complicates things. Shame. Kind of defeats re-usability of tasks/pipelines. – SYN Mar 01 '23 at 22:14