Pipeline: Variable interpolations for a TaskRun's name, etc.

[ImJasonH]

Expected Behavior

I'm able to reference the name of the TaskRun (and PipelineRun) I'm running inside of, from within the execution context.

Actual Behavior

I am not.

Additional Info

We could support this using variable interpolation, with a placeholder like $(inputs.taskRunName) or $(inputs.pipelineRunName) etc. -- if the TaskRun is not part of a PipelineRun its name should be "" (or possibly be flagged as invalid?)

There could also be variables for task name and pipeline name ($(inputs.taskName), etc.), which could also be "" (or invalid) if the TaskRun is not running from a predefined, named Task.

If we do this it probably also makes sense to be able to inject the namespace ($(inputs.namespace) and $(inputs.taskNamespace), since they can be in different namespaces. If it's a cluster-scoped Task, taskNamespace could be "" (or invalid, some sentinel value).

cc @csantanapr

/kind feature
/kind design

[skaegi]

Tekton uses labels pretty effectively so you can use an "env" valueFrom with fieldRef to get most Tekton information. For example inside a Step you can do...

env:
  - name: TASK
    valueFrom:
      fieldRef:
        fieldPath: metadata.labels['tekton.dev/task']

That works for tekton.dev/pipeline, tekton.dev/pipelineRun, tekton.dev/pipelineTask, tekton.dev/task, and tekton.dev/taskRun

Alternately you can use the Downward API to mount the labels as a volume to roughly the same effect.

All in all I think this is probably sufficient for now and we should consider closing.

[vdemeester]

@skaegi there is one trick to it though, those labels are on TaskRun and PipelineRun, but not on Task and Pipeline — I don't think it's a big deal as if we need it in the Task we may use parameters for it.

@ImJasonH overall, I tend to agree with @skaegi, not sure it is required as of today, that said, it might be nice to have that "easy" variable interpolation in the future.

[csantanapr]

I was able to use fieldRef to get the namespace.

What about using this values in conditions for example if namespace is “prod” skip this step or add this step. Is that possible today?

[R2wenD2]

/assign R2wenD2

[R2wenD2]

Since (inputs) is no longer a field on the resource, I'll use (runtime.) as the way to access names.

[bobcatfish]

Totally minor thing but in the working group update this morning i was typing runtime.taskRunName and i'm wondering if it would make sense to make it runtime.taskRun.name in case we want to expose other taskRun type attributes one day (e.g. startTime or something)

[R2wenD2]

Rather than runtime, lets use context.taskRunName so that the term runtime doesn't become overloaded. Please let me know if there are any concerns with adding a context scope.

[bobcatfish]

context sounds good to me!

@R2wenD2 what do you think about context.taskRun.name to open up the possibility of other taskRun attributes one day?

[jlpettersson]

I liked the idea with metadata.name since that is the actual field name. E.g. it is used in Downward API: fieldPath

[bobcatfish]

I liked the idea with metadata.name since that is the actual field name

If we go that path I think we'd still want to scope it since it might not be clear which object's metadata you're talking about, e.g. context.taskRun.metadata.name or taskRun.metadata.name

[R2wenD2]

I prefer context.taskRun.metadata.name - it makes it clear that we're using the name provided in the metadata for the taskRun (or pipeline, or pipelinerun) that is being run in the current context.

[R2wenD2]

I'll use "" as the default value for the name if a taskRun isn't a part of a pipelineRun.

[jlpettersson]

If it will start with context.taskRun.*

I think also context.taskRun.name would be a viable alternative. In the Go types, that is a shortcut for metadata.name. Then we keep that name slightly shorter for the end-users.

[R2wenD2]

After some investigation, (and discussion with @bobcatfish) It makes sense to make the context.pipelineRun.name available to the pipeline and context.taskRun.Name available to the task, using "" as a default when there is no taskRun or PipelineRun.

[R2wenD2]

/close

[tekton-robot]

@R2wenD2: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.