In both scenarios the Task's Workspace declaration remains the same and only the runtime Might use a PersistentVolumeClaim which is pre-populated withĭata for the Task to process. In a more complex system, however, a TaskRun For example, in isolation,Ī single TaskRun might simply provide an emptyDir volume that mounts quicklyĪnd disappears at the end of the run. This separation of concerns allows for a lot of flexibility. Runtime, a TaskRun provides the specific details of the Volume that is Tasks specify where a Workspace resides on disk for its Steps. A cache of build artifacts that speed up jobs.A mount point for common tools shared by an organization.A mount point for configurations held in ConfigMaps.A mount point for credentials held in Secrets.Workspaces can serve the following purposes: To defer to users and their TaskRuns when deciding which class of storage to use. Workspaces are similar to Volumes except that they allow a Task author Shared with other Tasks, create a PersistentVolumeClaim from a provided VolumeClaimTemplate, or simply an emptyDir that is discarded when the TaskRun In many ways: using a read-only ConfigMap or Secret, an existing PersistentVolumeClaim A TaskRun can make these parts of the filesystem available Workspaces allow Tasks to declare parts of the filesystem that need to be providedĪt runtime by TaskRuns. Using Persistent Volumes within a PipelineRun.Using PersistentVolumeClaims as VolumeSource.

Example PipelineRun definition using Workspaces.

Specifying Workspace order in a Pipeline and Affinity Assistants.

Examples of TaskRun definition using Workspaces.Mapping Workspaces in Tasks to TaskRuns.Setting a default TaskRun Workspace Binding.Isolating Workspaces to Specific Steps or Sidecars.Workspaces in Pipelines and PipelineRuns.

Code ready workspaces