Add support for Custom Tasks

[AlanGreene]

Is your feature request related to a problem ?

Dashboard should support displaying (at least) all resources provided by the core Tekton projects.

It does not currently display Custom Tasks (Run CRD) in any useful manner.

Describe the solution you'd like

Add support for displaying / interacting with Custom Tasks (Run CRD) https://github.com/tektoncd/community/blob/main/teps/0002-custom-tasks.md
https://github.com/tektoncd/pipeline/blob/master/docs/runs.md

Details TBD...

Describe alternatives you've considered

Additional context

[afrittoli]

I wanted to create this feature request... but it's already there :)
A first step here would be to able to display a Run.
I'm not sure we want to be display the specific custom tasks, as they're experimental.

If there's a way display them based on the CRD alone, we could do that, or support some kind of plugin mechanism to support them?

For things like task loops or pipelines in pipelines, we could stop relying on the status of a pipelinerun and instead search for all resources based on ownership information and/or labels, and that would give us a way to display all related resources.
It would require though being able to combine heterogeneous resources (taskrun, pipelinerun, run) in a single view.

[AlanGreene]

@afrittoli you mentioned on the Tekton working group this week that you were working on updating some of our existing CI jobs to use custom tasks. Can you point me at an example of some of those so I can get a feel for how they're being used in practice and how we might display something useful to the user?

[afrittoli]

This is an example of a task loop: https://dashboard.dogfooding.tekton.dev/#/namespaces/tekton-ci/pipelineruns/plumbing-unit-tests-flfmk?pipelineTask=clone-repo&step=clone

[AlanGreene]

Thanks for the link. Looking at another example where the task loop actually ran I see that we're already retrieving the relevant TaskRuns from the cluster but because the Dashboard client code isn't aware of custom tasks it just uses the first TaskRun matching the pipelineTask name to render in the UI.

Some quick notes (mostly to myself so I can pick this up again later):

• TaskRuns generated by the task loop custom task have the following labels:
  • "custom.tekton.dev/taskLoop": "golang-tests"
  • "custom.tekton.dev/taskLoopIteration": "1"
• ideally we would keep the Dashboard client agnostic to implementation details of individual custom tasks
  • as Andrea mentioned, a plugin model could be useful depending on how we decide to handle them
  • similar to what we do for retries, we could use the taskLoopIteration to decorate the UI and for the URL (only works for task loop)
  • is there some common display name we could use? Doesn't look like it, only common unique value would be TaskRun.metadata.name, uid, etc. Not exactly user friendly.
    • worth while considering as part of TEP-0047: Pipeline Task Display Name community#319 ? Enforce that custom tasks provide some sort of display name for the resulting TaskRuns
• should be able to handle these similarly to what we do for retries / conditions, and insert the additional TaskRuns into the list to be rendered by the TaskTree component. Just need to figure out naming / URL

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[AlanGreene]

/lifecycle frozen

[afrittoli]

It might be difficult or actually not possible for the dashboard to stay on top of the various custom controller.
I think a nice approach would be to build some kind of interface on the dashboard side that allows custom controller developers to maintain the dashboard components for their custom resource.
I have no idea how that would look like in practices though.

[mswiderski]

Thanks @AlanGreene for linking to this issue.

One approach I was thinking about was to rely on already existing dashboard extension for custom task that could provide at least the basic view over the custom task. Essentially when pipeline run view is opened in dashboard the custom task extension could be loaded.

If I am not mistaken dashboard already can look at Run resource that represents the custom task and which is the base for custom controllers. If that's the case custom controller could set a field on the Run (as it already does for reporting its status) to set the name of the custom CR so the dashboard could use it to display via the extension.

In addition the extension view could be enhanced to allow to set some extra info

• description
• url (that can be clickable to open in new tab)

(or event combine these two into link with text set to description)

I don't think this has to be very advanced as if there more info to provide I believe it should be taken off the dashboard and linked to some external resource that can deliver all that's needed.

Thoughts?

[AlanGreene]

Thanks for the interest and suggestions.

If I am not mistaken dashboard already can look at Run resource

It could but currently does not.

Last week I started working on some simple versions of the list + resource details pages for the Run resource. Initially this will be something similar to the PipelineResources page, providing a basic list of resources, and the details page for a single resource showing basic metadata + params + some other fields common to Run resources. A subsequent update (immediately after) would augment both of these pages with additional status / trigger information similar to the recent update of the TaskRuns / PipelineRuns list pages. I expect this to be included in the Dashboard v0.29 release in mid-September.

These initial versions will most likely not include surfacing this information on the PipelineRun details page quite yet, but will give us a better understanding of what information is currently available to the Dashboard and what is missing / needs to be added to the custom task API to make them more useful.

Some of the work for TEP-0100 (minimal status) also helps here as with that enabled we do currently render an entry in the PipelineRun details page for the custom task so at least users are aware there's a Run involved. It is not particularly useful at the moment as we don't render any log / status information for it yet. This would come as a follow up to the work I described above.

url (that can be clickable to open in new tab)

This is not applicable to all custom tasks. There are already a number of custom tasks available today that do not have an associated external service and for which a separate UI probably wouldn't make much sense.

I think what we need initially is some criteria for what the Dashboard itself should attempt to display vs. what should be handled by a more specialised external service. There is some common basic metadata + status information that I think the Dashboard should always display, and we would need some convention / API field to identify how to reference / link to any additional content the custom task deems relevant / necessary.

[mswiderski]

Last week I started working on some simple versions of the list + resource details pages for the Run resource. Initially this will be something similar to the PipelineResources page, providing a basic list of resources, and the details page for a single resource showing basic metadata + params + some other fields common to Run resources. A subsequent update (immediately after) would augment both of these pages with additional status / trigger information similar to the recent update of the TaskRuns / PipelineRuns list pages. I expect this to be included in the Dashboard v0.29 release in mid-September.

Looking forward to see how this will play out. thanks for the details

These initial versions will most likely not include surfacing this information on the PipelineRun details page quite yet, but will give us a better understanding of what information is currently available to the Dashboard and what is missing / needs to be added to the custom task API to make them more useful.

I believe this is the ultimate goal, so users can consider the pipeline run details page as the main entry point, which I think is already that for "normal" tasks.

Some of the work for TEP-0100 (minimal status) also helps here as with that enabled we do currently render an entry in the PipelineRun details page for the custom task so at least users are aware there's a Run involved. It is not particularly useful at the moment as we don't render any log / status information for it yet. This would come as a follow up to the work I described above.

Could you provide more info on this? Maybe some links to see what it is and how to enable that?

This is not applicable to all custom tasks. There are already a number of custom tasks available today that do not have an associated external service and for which a separate UI probably wouldn't make much sense.

Fully agree with that, though there will be for sure some that would benefit a lot from it. As mentioned, approvals are one of them as they target users/humans that expect UI to work with. Obviously it cannot be enforced on all custom tasks but have it as optional field that when set is presented to users as link would really improve user experience.

I think what we need initially is some criteria for what the Dashboard itself should attempt to display vs. what should be handled by a more specialised external service. There is some common basic metadata + status information that I think the Dashboard should always display, and we would need some convention / API field to identify how to reference / link to any additional content the custom task deems relevant / necessary.

And how do you see the extensions of custom tasks in this context? What role will they play? Maybe they can be somehow included in the details page of pipeline run link via the Run?

[AlanGreene]

Could you provide more info on this? Maybe some links to see what it is and how to enable that?

https://github.com/tektoncd/community/blob/main/teps/0100-embedded-taskruns-and-runs-status-in-pipelineruns.md
It reduces the volume of status information recorded in the PipelineRun by avoiding duplicating the TaskRun status, instead using child references to the TaskRun resources. This also reduces the frequency of updates to the PipelineRun resource, especially for Pipelines with many Tasks. You can enable it by settings the embedded-status feature flag to minimal.

Feature Being Deprecated	Deprecation Announcement	API Compatibility Policy	Earliest Date or Release of Removal
The PipelineRun.Status.TaskRuns and PipelineRun.Status.Runs fields are deprecated and will be removed.	v0.35.0	Beta	Jan 25, 2023

This will become the default behaviour in early 2023: https://tekton.dev/docs/pipelines/deprecations/

---

And how do you see the extensions of custom tasks in this context? What role will they play? Maybe they can be somehow included in the details page of pipeline run link via the Run?

I'm not sure I fully understand the questions. Can you clarify / expand on them? In particular, what do you mean by 'extensions of custom tasks'?

[mswiderski]

I'm not sure I fully understand the questions. Can you clarify / expand on them? In particular, what do you mean by 'extensions of custom tasks'?

This is the extension I was referring to https://github.com/tektoncd/dashboard/blob/main/docs/extensions.md

I already have an implementation of it for approval tasks and it works really well. You can see an example here.

So the idea I had was to link to that extension from the pipeline run details page based on the Run info and by that all the custom things could be shown via the extension.
Though the details page of the extension would have to be slightly improved to allow to display more info as currently it is quite limited. As can be noticed I (ab)use the labels to display some valuable info :)

How does this sound to you?

[AlanGreene]

Ah I understand now, thanks. What does a Run resource look like for your approval task?

This is the UI in the latest nightly build showing a Run resource for the wait-task, there's some more work in progress so this isn't the final form yet:

[mswiderski]

Ah I understand now, thanks. What does a Run resource look like for your approval task?

I am running on the latest released version of the dashboard so don't have that yet.

What's the procedure to install the nightly one? I noticed that images are in gcr so is it enough to just update the xml used for the releases? Currently use this one https://github.com/tektoncd/dashboard/releases/latest/download/tekton-dashboard-release.yaml

[AlanGreene]

Sorry I wasn't clear, I meant what does the YAML of the Run resource look like (e.g. the output of kubectl get run <run-name> -oyaml, to see if / how labels and other fields from your custom task are surfaced on the Run resource.

If you want to install the Dashboard nightly release you can find the release manifests in GCS, e.g.: https://storage.googleapis.com/tekton-releases-nightly/dashboard/latest/tekton-dashboard-release.yaml (same filenames as the full releases)

[mswiderski]

thanks, will provide you that hopefully today and will also try the nightly build too!

[mswiderski]

So here it is

apiVersion: tekton.dev/v1alpha1
kind: Run
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"tekton.dev/v1beta1","kind":"Pipeline","metadata":{"annotations":{},"name":"testpipeline2","namespace":"default"},"spec":{"tasks":[{"name":"deploy-dev-approval-task","params":[{"name":"pipeline","value":"$(context.pipelineRun.name)"},{"name":"description","value":"Approval from pipeline $(context.pipeline.name)"},{"name":"approvers","value":["john"]}],"taskRef":{"apiVersion":"tekton.automatiko.io/v1alpha1","kind":"ApprovalTask","name":"approvaltask"}},{"name":"deploy-dev-approved-task","params":[{"name":"decision","value":"APPROVED"},{"name":"comment","value":"$(tasks.deploy-dev-approval-task.results.comment)"}],"runAfter":["deploy-dev-approval-task"],"taskRef":{"name":"print-decision"},"when":[{"input":"$(tasks.deploy-dev-approval-task.results.decision)","operator":"in","values":["true"]}]},{"name":"deploy-dev-rejected-task","params":[{"name":"decision","value":"REJECTED"},{"name":"comment","value":"$(tasks.deploy-dev-approval-task.results.comment)"}],"runAfter":["deploy-dev-approval-task"],"taskRef":{"name":"print-decision"},"when":[{"input":"$(tasks.deploy-dev-approval-task.results.decision)","operator":"in","values":["false"]}]}]}}
  creationTimestamp: "2022-08-19T13:06:37Z"
  finalizers:
  - runs.tekton.dev/finalizer
  generation: 1
  labels:
    tekton.dev/memberOf: tasks
    tekton.dev/pipeline: testpipeline2
    tekton.dev/pipelineRun: testpipeline2-run-1660914397704
    tekton.dev/pipelineTask: deploy-dev-approval-task
  name: testpipeline2-run-1660914397704-deploy-dev-approval-task
  namespace: default
  ownerReferences:
  - apiVersion: tekton.dev/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: PipelineRun
    name: testpipeline2-run-1660914397704
    uid: 1cbc7d72-32f9-4e8d-84b6-376d3c808e86
  resourceVersion: "1130"
  uid: b2cdb19b-97ee-4f5b-ba7d-fc9ee0d4d01c
spec:
  params:
  - name: pipeline
    value: testpipeline2-run-1660914397704
  - name: description
    value: Approval from pipeline testpipeline2
  - name: approvers
    value:
    - john
  ref:
    apiVersion: tekton.automatiko.io/v1alpha1
    kind: ApprovalTask
    name: approvaltask
  serviceAccountName: default
  timeout: 59m59.9688125s
status:
  conditions:
  - lastTransitionTime: null
    message: Approval Task has been created
    reason: Succeeded
    status: Unknown
    type: ""
  extraFields: null
  startTime: "2022-08-19T13:06:38Z"

and how it looks like on the UI end

[AlanGreene]

hrmm, thanks for that. It confirmed what I suspected about the labels.

I wonder if labels from the custom task should be propagated to the Run, similar to how labels from a Task / Pipeline are propagated today. This would certainly simplify things from the Dashboard's perspective as we could read info from the Run resource for display in the PipelineRun without having to resolve and retrieve custom task resources too.

However, the labels would likely need to be present at the time the Run is created, so would not be useful for more dynamic content. it might be worth starting a broader discussion about this as it would affect the CLI and others too. Maybe in the #general channel on Slack to start with and we can go from there, see if there are others already considering this, and determine if we need to make changes to how Runs / custom tasks are implemented.

[mswiderski]

I wonder if labels from the custom task should be propagated to the Run, similar to how labels from a Task / Pipeline are propagated today. This would certainly simplify things from the Dashboard's perspective as we could read info from the Run resource for display in the PipelineRun without having to resolve and retrieve custom task resources too.

so that would be used to present data from within the Pipeline Run details, right? From my perspective (which could be really biased ;)) having a link to extension provided by custom task would be ideal.

And speaking about extension, what kind of enhancements we could make there? Currently it is very limited to what it can display. It does not even show spec or status information. Could we make the status info to be displayed?

If so, what would be possible approach to show an url as clickable link in the dashboard (extension details page)?

However, the labels would likely need to be present at the time the Run is created, so would not be useful for more dynamic content. it might be worth starting a broader discussion about this as it would affect the CLI and others too. Maybe in the #general channel on Slack to start with and we can go from there, see if there are others already considering this, and determine if we need to make changes to how Runs / custom tasks are implemented.

Please let me know if such discussion takes place I'd be more than happy to participate and provide input. thanks a lot!

[AlanGreene]

so that would be used to present data from within the Pipeline Run details, right?

Yes the labels could be used as a source of additional information, however I'm not suggesting they would be the only information used / displayed. I agree that allowing a custom task to provide its own custom UI is useful in many cases, we would still need to agree on a mechanism to communicate the correct URL to the Dashboard and other clients consuming / displaying these resources.

[mswiderski]

could we rely on the control that the custom resource always uses label with the name of the run?

  labels:
    tekton.dev/runName: testpipeline2-run-1660914397704-deploy-dev-approval-task

that way knowing the run name we could easily link to the custom resource with label selector. Would that bring any value?

[AlanGreene]

We've updated the Dashboard to include list and details pages for the new v1beta1 CustomRun resource (replacement for the deprecated v1alpha1 Run resource). Planning to revisit this issue to add support for displaying them on the PipelineRun details page in the near future as we're seeing more adoption of custom tasks, including in Tekton's own dogfooding.

[AlanGreene]

/area roadmap

[PoliM]

Just as feedback: I was a bit puzzled when I saw the task is in pending state within the pipeline run. First, I actually thought that I did something wrong with the state handling of the CustomRun in my controller. But then I found this issue, so it is clear now. Anyway, even a "not yet implemented" display within the pipeline run could be helpful.