-
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
adding label memberOf
to identify a taskRun in the pipeline
#4121
Conversation
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vdemeester 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 |
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.
Thanks for this, it sounds like a good idea!!
I would alter the implementation slightly though - see comments inline.
|
||
// check if a task is part of the finally section, add a label to identify it during the runtime | ||
if pr.Status.PipelineSpec != nil { | ||
for _, f := range pr.Status.PipelineSpec.Finally { | ||
if pipelineTask.Name == f.Name { | ||
labels[pipeline.GroupName+pipeline.FinallyLabelKey] = "true" | ||
break | ||
} | ||
} | ||
} |
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 doesn't feel like 100% right place for this, this function combines Task
spec and TaskRun
labels, which is why the function does not have access to the pipeline spec, and you have to go and get it from the status. Whether a PipelineTask
belongs to the finally
section is a Pipeline
level concern, so perhaps we could pass that info down to the createTaskRun
function, adding an extra boolean param:
if rprt.IsFinalTask(pipelineRunFacts) {
rprt.TaskRun, err = c.createTaskRun(ctx, rprt, pr, as.StorageBasePath(pr), getFinallyTaskRunTimeout, True)
} else {
rprt.TaskRun, err = c.createTaskRun(ctx, rprt, pr, as.StorageBasePath(pr), getTaskRunTimeout, False)
}
Alternatively you could use the GetPipelineFunc
function, which returns the spec from the status if available, or it will fetch it otherwise.
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.
thanks @afrittoli I think this was a reasonable place since its combining labels from the task
and taskRun
. Thanks for suggestion, I have moved it to getTaskrunLabels
function where we are adding other tekton.dev
labels such as tekton.dev/pipelineRun
and tekton.dev/pipelineTask
.
Also, its safe and reasonable to get the specification from the status
after we added it as a source of truth in #3941
createTaskRun
is growing complex with every new functionality we add. We really need a factory
style interface for the taskRun
and Run
instead of operating on the parameters.
@@ -929,6 +929,16 @@ func combineTaskRunAndTaskSpecLabels(pr *v1beta1.PipelineRun, pipelineTask *v1be | |||
labels[key] = value | |||
} | |||
} | |||
|
|||
// check if a task is part of the finally section, add a label to identify it during the runtime | |||
if pr.Status.PipelineSpec != nil { |
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.
If nil
we just ignore it and go on?
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 if
statement is just avoiding nil
pointer reference and this logic is mainly for the finally
task. By the time, a finally
taskRun is getting created, the status
is guaranteed to have the specification (which should be initialized before the first taskRun
is created).
The following is the coverage report on the affected files.
|
I am curious why I have a hunch that "memberOf" is better for the following reason: Imagine you have a cluster full of completed taskruns from your current Tekton install. You update to the new Tekton version which adds the "finallyTask" label. You query for "tekton.dev/finallyTask" of "true" and this returns all the finally tasks created after the label was introduced. Then you want the set of dag tasks so you query for "tekton.dev/finallyTask" of With "memberOf" you can query directly for all the finally taskruns created after the label was introduced, all of the dag taskruns created after the label was introduced, and all of the "other" taskruns created before the label was introduced. No problem if we do decide it's preferable to stick with a label of "true", just wanted to make sure this choice is discussed first. I'd much prefer we don't come back and add another label like "memberOf" later if we can simply introduce it now. WDYT? |
I share the same "thoughts" as @sbwsg, I think the "memberOf" approach could work really well here. |
The only reason to choose one over the other: |
f5287b0
to
169c27a
Compare
The following is the coverage report on the affected files.
|
169c27a
to
07fb2e2
Compare
The following is the coverage report on the affected files.
|
A label is added to a taskRun for a task which is part of the finally section. The label added is tekton.dev/finallyTask and set to true for a finally task.
07fb2e2
to
bee59de
Compare
The following is the coverage report on the affected files.
|
memeberOf
to identify a taskRun in the pipeline
memeberOf
to identify a taskRun in the pipelinememberOf
to identify a taskRun in the pipeline
<td><code>tekton.dev/memberOf</code></td> | ||
<td><code>TaskRuns</code> that are created automatically during the execution of a <code>PipelineRun</code>.</td> | ||
<td><code>TaskRuns, Pods</code></td> | ||
<td><code>tasks</code> or <code>finally</code> depending on the <code>PipelineTask</code>'s membership in the <code>Pipeline</code>.</td> |
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 👍 maps to the field names in the pipeline.
Thanks @pritidesai ! /lgtm |
Changes
A label named memberOf is added to all the taskRuns/Runs created while executing the pipeline based on their respective membership. A
taskRun
will have a labeltekton.dev/memberOf=tasks
for thetask
defined under "tasks" section and ataskRun
will have a labeltekton.dev/memberOf=finally
for thetask
defined under "finally" section.Implementation Iterations
Iteration1:
A label is added to a
taskRun
for atask
which is part of thefinally
section. The label added with a patterntekton.dev/finallyTask
and set totrue
for afinally
task.Closes #3721
Closes #3715
/kind feature
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
Release Notes