Skip to content
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

When using ${variable} in containerTemplate, it is not working #811

Closed
piyush-garg opened this issue Apr 29, 2019 · 6 comments
Closed

When using ${variable} in containerTemplate, it is not working #811

piyush-garg opened this issue Apr 29, 2019 · 6 comments
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. meaty-juicy-coding-work This task is mostly about implementation!!! And docs and tests of course but that's a given

Comments

@piyush-garg
Copy link
Contributor

Expected Behavior

Templating in containerTemplate should work.

Actual Behavior

Templating in containerTemplate is not working.

Steps to Reproduce the Problem

  1. Create a Cluster resource.
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: cluster-details
spec:
  type: cluster
  params:
  - name: url
    value: " "
  - name: name
    value: " "
  - name: username
    value: " "
  - name: token
    value: " "
  - name: cadata
    value: " "
  1. Create a task using cluster resource.
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: task-openshift-command-clusterresource
spec:
  containerTemplate:
    env:
      - name: "KUBECONFIG"
        value: "/workspace/${inputs.resources.clusterdetails.name}/kubeconfig"
  inputs:
    resources:
      - name: clusterdetails
        type: cluster
  steps:
    - name: foo
      image: ubuntu
      command:
        - /bin/bash
      args: ["-c", "env"]
  1. Create task run for the task
apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
  name: task-run-openshift-command-clusterresource
spec:
  taskRef:
    name: task-openshift-command-clusterresource
  inputs:
    resources:
      - name: clusterdetails
        resourceRef:
          name: cluster-details
  1. Check the logs of the step, it will show something like
oc logs task-run-openshift-command-clusterresource-pod-4645e9 -c build-step-foo
KUBECONFIG=/workspace/${inputs.resources.clusterdetails.name}/kubeconfig

Additional Info

Tekton version v0.3.1

@abayer abayer added kind/feature Categorizes issue or PR as related to a new feature. good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. meaty-juicy-coding-work This task is mostly about implementation!!! And docs and tests of course but that's a given and removed good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. labels Apr 29, 2019
@abayer
Copy link
Contributor

abayer commented Apr 29, 2019

Interesting - this is actually an enhancement, not a bug, fwiw, since variable templating has to be explicitly enabled for a field. This raises a question though - variable templating can only be done on explicitly specified string fields, which in the case of steps (i.e., Containers, so the logic we could trivially reuse for containerTemplate) currently means Name, Image, Args, Env values, Command, and Name, MountPath, and SubPath for VolumeMounts. Do we want to try to do a more general approach that, say, traversed the Container for all string fields and all fields that are structs with their string fields, etc? cc @bobcatfish @vdemeester for your thoughts.

@bobcatfish
Copy link
Collaborator

Do we want to try to do a more general approach that, say, traversed the Container for all string fields and all fields that are structs with their string fields, etc?

Yeah, I'm into that! I think it's confusing to only be doing it for a few fields.

@bobcatfish bobcatfish added the good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. label May 21, 2019
@abayer
Copy link
Contributor

abayer commented May 21, 2019

That's definitely doable, for sure.

@bobcatfish
Copy link
Collaborator

Note #982 is expanding the scope of values that can be templated, but not as broadly as we're suggesting here!

EliZucker added a commit to EliZucker/pipeline that referenced this issue Jun 25, 2019
Before, ApplyReplacements() would apply templating replacements to the containers within spec.Steps, but never to the single container at spec.ContainerTemplate. Note that this didn't work earlier because containerTemplate is merged with the container spec after templating is applied.

Isolate the container-specific templating in applyContainerReplacements()
and apply that logic to the containerTemplate field.

This addresses tektoncd#811.
tekton-robot pushed a commit that referenced this issue Jun 25, 2019
Before, ApplyReplacements() would apply templating replacements to the containers within spec.Steps, but never to the single container at spec.ContainerTemplate. Note that this didn't work earlier because containerTemplate is merged with the container spec after templating is applied.

Isolate the container-specific templating in applyContainerReplacements()
and apply that logic to the containerTemplate field.

This addresses #811.
@vdemeester
Copy link
Member

#1006 is in, this should be fixed 👼
/close

@tekton-robot
Copy link
Collaborator

@vdemeester: Closing this issue.

In response to this:

#1006 is in, this should be fixed 👼
/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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature. meaty-juicy-coding-work This task is mostly about implementation!!! And docs and tests of course but that's a given
Projects
None yet
Development

No branches or pull requests

5 participants