Allow declaring and passing resources to conditions#1151
Allow declaring and passing resources to conditions#1151tekton-robot merged 3 commits intotektoncd:masterfrom
Conversation
|
The following is the coverage report on pkg/.
|
|
[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 DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
The following is the coverage report on pkg/.
|
|
The following is the coverage report on pkg/.
|
|
The following is the coverage report on pkg/.
|
|
The following is the coverage report on pkg/.
|
bobcatfish
left a comment
There was a problem hiding this comment.
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 #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 |
There was a problem hiding this comment.
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
🙏
There was a problem hiding this comment.
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.
| // TargetPath is the path in workspace directory where the resource | ||
| // will be copied. | ||
| // +optional | ||
| TargetPath string `json:"targetPath"` |
There was a problem hiding this comment.
when i first saw this i wondered, why not use the existing type?
pipeline/pkg/apis/pipeline/v1alpha1/task_types.go
Lines 109 to 122 in bb85571
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
TaskResourceembeds the type and addsOutputImageDir - Maybe open an issue to explore changing
OutputImageDir(I'm not a big fan of the fact that the generic structTypeResourcehas an image specific field :S)
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
Nice! I like this a lot better!!!
(And yeah the original reason was to avoid the OutputImageDir field
There was a problem hiding this comment.
Done! ResourceInput might be confusing with Input Resources so I chose ResourceDeclaration though maybe DecalaredResource is better 🤔
There was a problem hiding this comment.
Just don't tell @dlorenc that i recommended embedding.... 😇
pkg/reconciler/v1alpha1/pipelinerun/resources/conditionresolution.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} |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
pkg/reconciler/v1alpha1/pipelinerun/resources/conditionresolution.go
Outdated
Show resolved
Hide resolved
pkg/reconciler/v1alpha1/pipelinerun/resources/conditionresolution.go
Outdated
Show resolved
Hide resolved
| // Finally add it to the resolved resources map | ||
| rr[r.Name] = gotResource | ||
| } | ||
| rcc.ResolvedResources = rr |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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!
|
The following is the coverage report on pkg/.
|
ooo that might be legit |
|
/test pull-tekton-pipeline-integration-tests |
|
The following is the coverage report on pkg/.
|
|
The following is the coverage report on pkg/.
|
|
/hold |
pkg/reconciler/pipelinerun/resources/pipelinerunresolution_test.go
Outdated
Show resolved
Hide resolved
|
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? |
|
@afrittoli Thanks...Yes, will squash and also going to make a couple of changes later today based on @bobcatfish 's review comment. |
|
The following is the coverage report on pkg/.
|
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>
|
The following is the coverage report on pkg/.
|
|
/hold cancel |
🤔 |
|
/test pull-tekton-pipeline-build-tests |
bobcatfish
left a comment
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
(Maybe this is ResourceDeclaration)?
| } | ||
| }) | ||
| } | ||
| } |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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 |
|
/test pull-tekton-pipeline-go-coverage |
|
The following is the coverage report on pkg/.
|
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 :( |
|
Something might be up with that coverage bot anyway #1248 |
|
/lgtm |
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