-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Add support for from
usage in Pipeline Conditions
#1527
Conversation
from
usage in Pipeline Conditionsfrom
usage in Pipeline Conditions
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
from
usage in Pipeline Conditionsfrom
usage in Pipeline Conditions
The following is the coverage report on pkg/.
|
/cc @sbwsg @afrittoli @bobcatfish @vdemeester I haven't fully kept up with all the cool new resource stuff but do you think adding support for the |
Yes I think so! Supporting it for the existing pipeline resources implementation makes sense to me. |
@@ -326,3 +337,82 @@ func TestBuild_Invalid(t *testing.T) { | |||
}) | |||
} | |||
} | |||
|
|||
func TestBuild_ConditionResources(t *testing.T) { | |||
// a,b, c, d := regularTask |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove dead code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, more like a outdated comment 😅
/lgtm |
The following is the coverage report on pkg/.
|
/test pull-tekton-pipeline-integration-tests |
/lgtm |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, this is really useful!
spec: | ||
inputs: | ||
outputs: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, I though we deprecated git
pipeline resource as output, at least until we have an actual output resource - only holding off the LGTM to clarify this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, did not know that....I can switch the example to a GCS resource or something
Conditions: []v1alpha1.PipelineTaskCondition{cond2DependsOnB}, | ||
} | ||
|
||
// a b c |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice :)
@@ -152,15 +152,6 @@ type PipelineDeclaredResource struct { | |||
Type PipelineResourceType `json:"type"` | |||
} | |||
|
|||
// PipelineConditionResource allows a Pipeline to declare how its DeclaredPipelineResources | |||
// should be provided to a Condition as its inputs. | |||
type PipelineConditionResource struct { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I understand this was removed to make the logic in the code simpler, since you have to deal with PipelineTaskInputResource
only; I wonder if we may need different behaviours for task input resources and condition resources, but we can still add this back if becomes necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I don't think we do at the moment; but if we do we can add this back later on. Right now, this is basically an unused/extra level of indirection
Thanks for the review @afrittoli Looks like there have been some major changes to the DAG....so the rebase will need some work..I'll give that shot on Friday! |
I don't think they are that major 😅 but ping me if you need help 😝 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Naive question, can I create a deadlock with that from
? Like refering to a task that has a from on the current task. Something like the following ?
tasks:
- name: first-create-file
taskRef:
name: create-file
resources:
outputs:
- name: workspace
resource: source-repo
- name: then-check
conditions:
- conditionRef: "file-exists"
resources:
- name: workspace
resource: source-repo
from: [then-again]
taskRef:
name: echo-hello
- name: then-again
resources:
outputs:
- name: workspace
resource: source-repo
from: [then-check]
taskRef:
name: echo-hello
Asking because I think we should try to prevent that from happening.
I'd hope not 😅 I think we detect the cycles in the DAG...let me verify |
Tried this out:
webhook validation failed:
|
/test pull-tekton-pipeline-integration-tests |
/test pull-tekton-pipeline-build-tests |
/approve |
Resources in Pipeline Conditions can now declare that they depend on the output of previous tasks using the `from` clause. Using `from` in a conditional resource implies ordering for the pipeline task i.e. if task B has a condition (say, C) that takes in an output resource from task A, task A will run first, followed by the conditional C, and then B Signed-off-by: Dibyo Mukherjee <[email protected]>
/test pull-tekton-pipeline-integration-tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sbwsg, vdemeester The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/test pull-tekton-pipeline-integration-tests |
1 similar comment
/test pull-tekton-pipeline-integration-tests |
Changes
Resources in Pipeline Conditions can now declare that they depend on the
output of previous tasks using the
from
clause. Usingfrom
in aconditional resource implies ordering for the pipeline task i.e. if
task B has a condition (say, C) that takes in an output resource from
task A, task A will run first, followed by the conditional C, and then B
Fixes #1256
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes