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

Allow declaring and passing resources to conditions #1151

Merged
merged 3 commits into from
Aug 30, 2019

Conversation

dibyom
Copy link
Member

@dibyom dibyom commented Aug 2, 2019

Changes

Allow condition to declare pipeline resources in their definitions.
The resource can be accessed by the condition container during a check.
Only input resources are supported. The declared resources can be specified
in a PipelineTaskCondition and variable substitution for the resource is
supported just like with a TaskResource.

Fixes #1021

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

Release Notes

Adds resource support for conditionals. Conditions have to declare 
the resources they can use and these can be passed in via the
Pipeline and PipelineRun spec similar to TaskResources. 

@tekton-robot tekton-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 2, 2019
@googlebot googlebot added the cla: yes Trying to make the CLA bot happy with ppl from different companies work on one commit label Aug 2, 2019
@tekton-robot tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Aug 2, 2019
@dibyom dibyom changed the title WIP: Allow declaring and passing resources to conditions Allow declaring and passing resources to conditions Aug 2, 2019
@tekton-robot tekton-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 2, 2019
@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/v1alpha1/pipelinerun/resources/conditionresolution.go 80.0% 71.4% -8.6
pkg/reconciler/v1alpha1/pipelinerun/resources/pipelinerunresolution.go 90.5% 85.9% -4.6

@dibyom dibyom changed the title Allow declaring and passing resources to conditions WIP: Allow declaring and passing resources to conditions Aug 2, 2019
@tekton-robot tekton-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 2, 2019
@tekton-robot
Copy link
Collaborator

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dibyom

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@tekton-robot tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 5, 2019
@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/v1alpha1/pipelinerun/pipelinerun.go Do not exist 82.3%
pkg/reconciler/v1alpha1/pipelinerun/resources/conditionresolution.go 80.0% 76.9% -3.1
pkg/reconciler/v1alpha1/pipelinerun/resources/pipelinerunresolution.go 90.5% 85.9% -4.6

@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/v1alpha1/pipelinerun/pipelinerun.go Do not exist 82.1%
pkg/reconciler/v1alpha1/pipelinerun/resources/conditionresolution.go 80.0% 83.6% 3.6
pkg/reconciler/v1alpha1/pipelinerun/resources/pipelinerunresolution.go 90.5% 91.1% 0.6

@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/v1alpha1/pipelinerun/pipelinerun.go Do not exist 82.2%
pkg/reconciler/v1alpha1/pipelinerun/resources/conditionresolution.go 80.0% 83.6% 3.6
pkg/reconciler/v1alpha1/pipelinerun/resources/pipelinerunresolution.go 90.5% 91.1% 0.6

@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/v1alpha1/pipelinerun/pipelinerun.go Do not exist 82.2%
pkg/reconciler/v1alpha1/pipelinerun/resources/conditionresolution.go 80.0% 83.6% 3.6
pkg/reconciler/v1alpha1/pipelinerun/resources/pipelinerunresolution.go 90.5% 91.1% 0.6

@dibyom dibyom changed the title WIP: Allow declaring and passing resources to conditions Allow declaring and passing resources to conditions Aug 6, 2019
@tekton-robot tekton-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Aug 6, 2019
Copy link
Collaborator

@bobcatfish bobcatfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty cool! I agree with adding this functionality for sure :D I left a few comments, mostly just some refactoring ideas.

Couple other thoughts:

  • Looks like there are a couple lines in conditionresolution.go not covered that would probably be easy to cover with a couple extra test cases
  • I merged Change variable interpolation braces #1172 so any comments, examples using ${} should use $() instead (and it should support both but as long as you're calling the same logic it should be fine! might want to add a test case or two just in case) 😭 🙏

provide the Condition container step with data or context that is needed to perform the check.

Input resources, like source code (git), are dumped at path
`/workspace/resource_name` within a mounted
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm I'm thinking that we should create a separate section in the resources.md docs for how the paths work - the docs are a bit spread out, e.g.

https://github.com/tektoncd/pipeline/blob/master/docs/tasks.md#controlling-where-resources-are-mounted
and
https://github.com/tektoncd/pipeline/blob/master/docs/taskruns.md#overriding-where-resources-are-copied-from
And even the path templating (like you said!)
https://github.com/tektoncd/pipeline/blob/master/docs/tasks.md#templating

But I think/hope that both of those docs would apply to this use of resources as well? In which case it'd be good if we can put all those docs in one place and link to them from here and from the other places

🙏

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, the thing is since things like targetPath are part of TaskResource, they are in the tasks doc. Now with conditions, there is some duplication. I'll add a section in the resource doc on how to use resources in conditions and tasks. That section will link to both the Task and Condition resource docs and contain the common bits e.g. targetPaths, the path variable substitution.

I'm thinking of doing this in a follow-up PR.

examples/pipelineruns/conditional-pipelinerun.yaml Outdated Show resolved Hide resolved
examples/pipelineruns/conditional-pipelinerun.yaml Outdated Show resolved Hide resolved
// TargetPath is the path in workspace directory where the resource
// will be copied.
// +optional
TargetPath string `json:"targetPath"`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when i first saw this i wondered, why not use the existing type?

type TaskResource struct {
// Name declares the name by which a resource is referenced in the Task's
// definition. Resources may be referenced by name in the definition of a
// Task's steps.
Name string `json:"name"`
// Type is the type of this resource;
Type PipelineResourceType `json:"type"`
// TargetPath is the path in workspace directory where the task resource
// will be copied.
// +optional
TargetPath string `json:"targetPath"`
// Path to the index.json file for output container images.
// +optional
OutputImageDir string `json:"outputImageDir"`

I'm guessing it's b/c of the OutputImageDir field on the condition resource, is that correct? if that's the only reason then im thinking maybe we could do something like:

  • Define one type (maybe called something like ResourceInput? or something better XD)
  • Use this new type directly for conditions
  • Make it so that TaskResource embeds the type and adds OutputImageDir
  • Maybe open an issue to explore changing OutputImageDir (I'm not a big fan of the fact that the generic struct TypeResource has an image specific field :S)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe open an issue to explore changing OutputImageDir (I'm not a big fan of the fact that the generic struct TypeResource has an image specific field :S)

We can probably leave that for now - between the resource extensibility design and a proposal im making for treating output images differently i think we're gonna get it fixed :D

but in the meantime embedding might be an okay solution!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I like this a lot better!!!
(And yeah the original reason was to avoid the OutputImageDir field

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done! ResourceInput might be confusing with Input Resources so I chose ResourceDeclaration though maybe DecalaredResource is better 🤔

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just don't tell @dlorenc that i recommended embedding.... 😇

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤣 🤣 🤣

pkg/reconciler/v1alpha1/pipelinerun/pipelinerun.go Outdated Show resolved Hide resolved
}

// Prepends inputs. to all resource template strings so that they can be replaced by
// taskrun variable substitution e.g. ${resources.name.key} to ${inputs.resources.name.key}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm this seems like a bit of a hack 😇 im thinking in the long run we should refactor this so we can call the templating (now called substitution 😅 ) functions without needing this hack first (np if we want to do this in a separate PR or even open an issue about it)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed pretty hacky! I think it should be simple enough to do the resource substitution completely here. I'll give it a shot in this PR

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done!

// Finally add it to the resolved resources map
rr[r.Name] = gotResource
}
rcc.ResolvedResources = rr
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this kinda feels like it could be a separate function, what do you think?

resolveConditionChecks could even become ResolveConditionChecks and be called by the reconciler after calling ResolvePipelineRun - that would make it so ResolvePipelineRun and its unit tests could be simpler, and you'd no longer need to distinguish between different kinds of errors

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, I split the resource resolution into a separate function. There is definitely a lot of scope to refactor the pipelineState resolution -- besides resolving the conditionChecks separately, another thing that might help (particularly with #1023) would be changing the PipelineState from just being a slice of the ResolvedTasks to having a reference to the Dag nodes.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is definitely a lot of scope to refactor the pipelineState resolution

Yeah probably too much to do all at ounce - but thanks for the incremental improvement!

@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/v1alpha1/pipelinerun/pipelinerun.go 82.4% 82.2% -0.2
pkg/reconciler/v1alpha1/pipelinerun/resources/conditionresolution.go 80.0% 83.9% 3.9
pkg/reconciler/v1alpha1/pipelinerun/resources/pipelinerunresolution.go 94.5% 94.9% 0.3

@bobcatfish
Copy link
Collaborator

I0816 14:00:38.929] ERROR: test demo-condtional-pr-list-files-1-gknrc-file-exists-68bvx=SucceededFalse but should be succeededtrue
I0816 14:00:38.930] ERROR: one or more YAML tests failed

ooo that might be legit

@bobcatfish
Copy link
Collaborator

/test pull-tekton-pipeline-integration-tests

@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/pipelinerun/pipelinerun.go Do not exist 82.2%
pkg/reconciler/pipelinerun/resources/conditionresolution.go 80.0% 83.9% 3.9
pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go 94.5% 94.9% 0.3

@tekton-robot tekton-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Aug 26, 2019
@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/reconciler/pipelinerun/pipelinerun.go Do not exist 82.2%
pkg/reconciler/pipelinerun/resources/conditionresolution.go 80.0% 83.3% 3.3
pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go 94.5% 94.9% 0.3

@dibyom
Copy link
Member Author

dibyom commented Aug 26, 2019

/hold

@tekton-robot tekton-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 26, 2019
pkg/apis/pipeline/v1alpha1/pipeline_types.go Outdated Show resolved Hide resolved
docs/conditions.md Outdated Show resolved Hide resolved
test/builder/condition.go Outdated Show resolved Hide resolved
@afrittoli
Copy link
Member

Thanks for this! I will review it now. A quick note, there are three commits in this PR, do you plan to squash or if not could you amend the commit messages of the last two commits?

@dibyom
Copy link
Member Author

dibyom commented Aug 29, 2019

@afrittoli Thanks...Yes, will squash and also going to make a couple of changes later today based on @bobcatfish 's review comment.

@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/pipeline/v1alpha1/resource_paths.go Do not exist 100.0%
pkg/reconciler/pipelinerun/pipelinerun.go Do not exist 82.2%
pkg/reconciler/pipelinerun/resources/conditionresolution.go 80.0% 83.6% 3.6
pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go 94.5% 94.9% 0.3
pkg/reconciler/taskrun/resources/apply.go 97.6% 100.0% 2.4

Allow condition to declare pipeline resources in their definitions.
The resource can be accessed by the condition container during a check.
Only input resources are supported. The declared resources can be specified
in a PipelineTaskCondition and variable substitution for the resource is
supported just like with a `TaskResource`.

Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
Creates a new internal struct called `ResourceDeclaration`.
TaskResources now embed this and add additional fields such as
`OutputImageDir` while `ConditionResource` has simply been replaced
with this new type.

Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
Previously, we'd change the variable names to what the
taskrun format and then rely on the taskrun's variable
substitution logic. This approach is hacky and now we
explicitly replace the resource variable strings with the
right values without relying on the TaskRun logic.

In the future, we should consider doing the same for parameter
variables as well.

Signed-off-by: Dibyo Mukherjee <dibyo@google.com>
@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/pipeline/v1alpha1/resource_paths.go Do not exist 100.0%
pkg/reconciler/pipelinerun/pipelinerun.go 94.4% 82.2% -12.2
pkg/reconciler/pipelinerun/resources/conditionresolution.go 80.0% 83.6% 3.6
pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go 94.5% 95.0% 0.4
pkg/reconciler/taskrun/resources/apply.go 97.6% 100.0% 2.4

@dibyom
Copy link
Member Author

dibyom commented Aug 30, 2019

/hold cancel

@tekton-robot tekton-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 30, 2019
@dibyom
Copy link
Member Author

dibyom commented Aug 30, 2019

pkg/reconciler/pipelinerun/pipelinerun.go 94.4% 82.2% -12.2

🤔

@dibyom
Copy link
Member Author

dibyom commented Aug 30, 2019

/test pull-tekton-pipeline-build-tests

Copy link
Collaborator

@bobcatfish bobcatfish left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a couple super minor comments! I was gonna lgtm but I just saw the -12.2% coverage thing so maybe I'll wait for that XD

value: my-value
resources:
- name: workspace
resource: source-repo
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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??)

type PipelineConditionResource struct {
// Name is the name of the PipelineResource as declared by the Condition.
Name string `json:"name"`
// Resource is the name of the DeclaredPipelineResource to use.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm this is kinda odd but also really minor - these comments refer to DeclaredPipelineResource but I don't think that DeclaredPipelineResource is a type that's actually defined anywhere?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Maybe this is ResourceDeclaration)?

}
})
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

haha yeessssss i love the super focused test coverage XD

for _, tc := range tcs {
t.Run(tc.name, func(t *testing.T) {
if actual := v1alpha1.OutputResourcePath(tc.resource); actual != tc.expected {
t.Errorf("Unexpected output resource path: %s", actual)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can be helpful to included the expected path in the error message as well

// +optional
TargetPath string `json:"targetPath,omitempty"`
// Path to the index.json file for output container images.
ResourceDeclaration
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉 😇

@dibyom
Copy link
Member Author

dibyom commented Aug 30, 2019

/test pull-tekton-pipeline-go-coverage

@tekton-robot
Copy link
Collaborator

The following is the coverage report on pkg/.
Say /test pull-tekton-pipeline-go-coverage to re-run this coverage report

File Old Coverage New Coverage Delta
pkg/apis/pipeline/v1alpha1/resource_paths.go Do not exist 100.0%
pkg/reconciler/pipelinerun/pipelinerun.go 94.4% 82.2% -12.2
pkg/reconciler/pipelinerun/resources/conditionresolution.go 80.0% 83.6% 3.6
pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go 94.5% 95.0% 0.4
pkg/reconciler/taskrun/resources/apply.go 97.6% 100.0% 2.4

@dibyom
Copy link
Member Author

dibyom commented Aug 30, 2019

I just saw the -12.2% coverage thing so maybe I'll wait for that XD

Not sure this is accurate. The coverage for that file is around 82.2% according to another recently updated PR: #1204 (comment)

Trying to run this locally fails with a data race :(
(I think this is the same issue as #1124)

@bobcatfish
Copy link
Collaborator

Something might be up with that coverage bot anyway #1248

@bobcatfish
Copy link
Collaborator

/lgtm

@tekton-robot tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Aug 30, 2019
@tekton-robot tekton-robot merged commit ecddd2f into tektoncd:master Aug 30, 2019
@dibyom dibyom deleted the cond-resources branch August 30, 2019 18:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cla: yes Trying to make the CLA bot happy with ppl from different companies work on one commit lgtm Indicates that a PR is ready to be merged. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Conditionals: Allow access to pipeline resources
5 participants