-
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
Allow declaring and passing resources to conditions #1151
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
Needs 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/.
|
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.
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 |
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.
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.
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.
// 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.
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?
pipeline/pkg/apis/pipeline/v1alpha1/task_types.go
Lines 109 to 122 in bb85571
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 addsOutputImageDir
- Maybe open an issue to explore changing
OutputImageDir
(I'm not a big fan of the fact that the generic structTypeResource
has an image specific field :S)
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.
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.
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
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.
Done! ResourceInput
might be confusing with Input Resources so I chose ResourceDeclaration
though maybe DecalaredResource
is better 🤔
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.
Just don't tell @dlorenc that i recommended embedding.... 😇
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.
🤣 🤣 🤣
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.
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)
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.
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
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.
done!
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.
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
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.
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.
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!
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 |
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.
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.
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. |
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Maybe this is ResourceDeclaration
)?
} | ||
}) | ||
} | ||
} |
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.
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.
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 |
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.
🎉 😇
/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