Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Link workspaces together through a pipeline. #2017

Closed
ghost opened this issue Feb 7, 2020 · 1 comment
Closed

Link workspaces together through a pipeline. #2017

ghost opened this issue Feb 7, 2020 · 1 comment
Labels
kind/design Categorizes issue or PR as related to design. kind/feature Categorizes issue or PR as related to a new feature.

Comments

@ghost
Copy link

ghost commented Feb 7, 2020

Expected Behavior

It should be possible to express in a pipeline that "this task's workspace is shared with that other task, and it should write to it before I read from it". And from this declaration Tekton should be able to infer that one task should execute before the other one. We implemented / prototyped this using a "from" clause similar to that of PipelineResources but there was some pushback related to the syntax as well as the perceived need for the clause. So instead of merging that I'm capturing the issue here and we can revisit it either when there's clear demand or it otherwise becomes obvious that it's a necessary addition.

The first implementation's syntax looked like this:

# in a pipeline spec
  tasks:
    - name: task1
      taskRef:
        name: write-to-workspace
      workspaces:
        - name: output
          workspace: pipeline-ws1
    - name: task2
      taskRef:
        name: read-from-workspace
      workspaces:
        - name: src
          from:
            task: task1
            name: output

The important part to note is the "from" clause in the second task that points at the prior task's workspace. The PR that implemented this used that information to order the tasks such that task1 would execute before task2 could. A PVC could then be threaded from one to the other through a workspace binding.

This issue doesn't mandate that we should continue to use that design. We can introduce any other syntax we want if the feature becomes necessary. We could potentially use variable substitution here but it's unclear precisely which value would be substituted into which other field. However the nice thing about using a variable would be that it has parity with the task results linking that is being worked on.

@ghost ghost added kind/feature Categorizes issue or PR as related to a new feature. kind/design Categorizes issue or PR as related to design. labels Feb 7, 2020
@ghost
Copy link
Author

ghost commented Feb 7, 2020

Jeez I forgot I already opened an issue for this. This one's a dupe of #1878

@ghost ghost closed this as completed Feb 7, 2020
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/design Categorizes issue or PR as related to design. kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

0 participants