You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Custom tasks in Tekton allow to specify workspaces. We should allow to pass a workspace with the name source and reject all other workspaces.
The source workspace should be passed to the BuildRun and from there to the Tekton TaskRun that implements the BuildRun. And here it becomes interesting as we will need an extension in Shipwright Build. To be designed, but two options:
generic volume support for the source, not my favorite
we introduce a source type PipelineWorkspace. In this case, Shipwright will look at the Run/CustomRun which owns the BuildRun. There it should find the workspace named source. And then it will need to look in the owner again which is the PipelineRun to determine what backs the workspace. And then we use this. Interesting will be how we support the affinity assistant capability of Tekton which will be needed if the user uses a PVC which is backed by a hostpath.
Custom tasks in Tekton allow to specify workspaces. We should allow to pass a workspace with the name
source
and reject all other workspaces.The source workspace should be passed to the BuildRun and from there to the Tekton TaskRun that implements the BuildRun. And here it becomes interesting as we will need an extension in Shipwright Build. To be designed, but two options:
source
. And then it will need to look in the owner again which is the PipelineRun to determine what backs the workspace. And then we use this. Interesting will be how we support the affinity assistant capability of Tekton which will be needed if the user uses a PVC which is backed by a hostpath.Tekton docs: https://tekton.dev/docs/pipelines/customruns/#specifying-workspaces
The text was updated successfully, but these errors were encountered: