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

Support from clause for resources in Conditionals #1256

Closed
dibyom opened this issue Aug 30, 2019 · 0 comments · Fixed by #1527
Closed

Support from clause for resources in Conditionals #1256

dibyom opened this issue Aug 30, 2019 · 0 comments · Fixed by #1527
Assignees
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@dibyom
Copy link
Member

dibyom commented Aug 30, 2019

Expected Behavior

Resources in Conditions should be able to use output resources from other tasks using the from clause. This will become very important when we have resource immutability and new output resources are created from the original resource spec.

On generating the pod for conditions, if 'from' is used for the condition's resource, the pod could mount to that resource (e.g. /pvc/) then copy to condition resource's workspace.
This is similar to Task usage in the pipeline.

Actual Behavior

No support 'from', any Git resource declared for the condition will be handled as normal Git fetch.

Steps to Reproduce the Problem

  1. Define a normal Condition check with resource type Git
  2. Use that Condition in the pipeline, expect 'from' can be used

Additional Info

Originally posted by @bobcatfish in #1151:

Hmm something just occurred to me - can conditions use the from clause for resources? If there is more work to do here I totally would expect that in a follow up PR, but basically what I'm thinking is that if a Task is getting a resource from another Task, but has some condition to execute on that resource, the user would probably want the condition to be executed on that same task
e.g. a Task has a git output (assuming a world where a git output creates a new commit), another Task gets the git resource from that task, but the condition says only if the most recent commit changed XYZ files (kind of contrived but maybe??)

Issue updated with #1499

@dibyom dibyom added the kind/feature Categorizes issue or PR as related to a new feature. label Aug 30, 2019
@bobcatfish bobcatfish added this to the Pipelines 0.8 🐱 milestone Sep 10, 2019
@dibyom dibyom self-assigned this Oct 15, 2019
dibyom added a commit to dibyom/pipeline that referenced this issue Oct 22, 2019
While working on tektoncd#1256 I noticed that we had two different functions
to validate that the `from` field. One was being used by the webhook,
and the other in the reconciler. I replaced the `ValidateFrom` in the
reconciler with the more general `Validate` that validates the entire
pipeline spec, not just one field. In addition, I fixed some of the
reconciler tests that were now failing due to having an invalid pipeline
spec e.g. pipeline tasks with no name.

Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
tekton-robot pushed a commit that referenced this issue Oct 30, 2019
While working on #1256 I noticed that we had two different functions
to validate that the `from` field. One was being used by the webhook,
and the other in the reconciler. I replaced the `ValidateFrom` in the
reconciler with the more general `Validate` that validates the entire
pipeline spec, not just one field. In addition, I fixed some of the
reconciler tests that were now failing due to having an invalid pipeline
spec e.g. pipeline tasks with no name.

Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
@bobcatfish bobcatfish modified the milestones: Pipelines 0.9 🐱, Pipelines 1.1 / Post-beta 🐱 Oct 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants