copy the labels from Task ->TaskRun to the generated Pod
#458
Comments
|
I'm going to start working on this shortly, fyi. |
|
/assign @abayer |
PipelineRun to the generated Task PodTaskRun to the generated Pod
TaskRun to the generated PodTask ->TaskRun to the generated Pod
Previously, labels were propagated from TaskRun to Build, but not from Build to Pod. This PR fixes that, and also propagates labels from PipelineRun to TaskRun, so that users are more easily able to filter, identify, and query Pods created by Build Pipeline. In all cases, if a user specifies a label whose key overlaps with one of the labels that we set automatically, the user's label is ignored. As mentioned in taskrun_test.go, the current tests do not fully demonstrate that the TaskRun to Pod propagation works correctly since they use Build as an intermediate form for comparison. Fixes tektoncd#458
Previously, labels were propagated from TaskRun to Build, but not from Build to Pod. This PR fixes that, and also propagates labels from PipelineRun to TaskRun, so that users are more easily able to filter, identify, and query Pods created by Build Pipeline. In all cases, if a user specifies a label whose key overlaps with one of the labels that we set automatically, the user's label is ignored. As mentioned in taskrun_test.go, the current tests do not fully demonstrate that the TaskRun to Pod propagation works correctly since they use Build as an intermediate form for comparison. Fixes tektoncd#458
|
I'm actually picking this up from Andrew :) Looking at the code, propagation from PipelineRun to TaskRun to Pod (through Build in memory) is pretty trivial, but propagation from Task through to Pod is a little trickier because right now most of the relevant data structures only pass a TaskSpec around but we'd need to full Task or at least its metadata. I discussed with @jstrachan and he was ok with leaving out Task for now if it requires significant extra work, but noted that it would be ideal to be able to use a single label to obtain all resources related to a build. |
Previously, labels were propagated from TaskRun to Build, but not from Build to Pod. This PR fixes that, and also propagates labels from PipelineRun to TaskRun, so that users are more easily able to filter, identify, and query Pods created by Build Pipeline. In all cases, if a user specifies a label whose key overlaps with one of the labels that we set automatically, the user's label is ignored. As mentioned in taskrun_test.go, the current tests do not fully demonstrate that the TaskRun to Pod propagation works correctly since they use Build as an intermediate form for comparison. Fixes #458
|
It feels kinda like the chain should go all the way:
What do you think?
Hooray!! 🎉 :D
hm good point - I'm sure we can figure out a way to make it work :D in the worse case we could always use the Task client to retrieve the Task again 🤔 - but also adding the labels to the resolved task resources or similar might not be too bad?
@dwnusbaum relevant note, @tanner-bruce actually added a bit of label propagation in #199 (see the docs here which for my sins I deleted in #460 because I couldn't figure out where to put them 😇 (not a very good excuse) |
|
lol totally late to the party and the PR, sorry @dwnusbaum 🤣 |
|
I am really tempted to put in a last request to add some docs on this but considering that I deleted the last ones I wouldn't blame you if you ignored me @dwnusbaum 😅 😅 😅 (in retrospect I should not have deleted them...) |
I agree, it was just really easy to add the *Run propagation so I went for that first. Do you think it makes sense to open another issue specifically for Pipeline and Task label propagation, or just reopen this one? (I don't have permission to update the title/description so it might be cleaner to use a new issue)
That was what I was thinking too, but it seemed like at that point we might as well just have the whole Task in case anything needed additional metadata in the future (although maybe YAGNI...). From my quick look it seemed like there was no particular reason that we dropped the Task and just carried around the TaskSpec, so it would just be a matter of tweaking the struct and fixing up the use sites, but maybe I was missing something. Definitely deserves a closer look!
That seems fair to me 😄 I will try to whip something up from what was added in #199 and explain that custom labels are supported in addition to the labels we add to everything automatically. I am working on updating the e2e tests to check label propagation as well so I'll probably submit a PR for all of that. |
|
e2e tests updated and docs added in #500 |
niiiiiice 🙏 😍
A new issue is probably more satisfying too! :D |
Created #501 😄 |
Expected Behavior
If we add labels to a
Taskthey should get replicated to theTaskRunthen thePodthats created so that you can more easily query/filter TaskRuns and Pods.Actual Behavior
Labels on a
Taskare ignoredIf there are concerns over copying the labels, maybe there could be a way to specify which labels to copy/not copy?
The text was updated successfully, but these errors were encountered: