Why does the input resource name have to show up in pathToDockerFile and pathToContext

[houshengbo]

This is the example used at the page: https://github.com/tektoncd/pipeline/blob/master/docs/tutorial.md#task-inputs-and-outputs to create a task:

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: build-docker-image-from-git-source
spec:
  inputs:
    resources:
      - name: docker-source
        type: git
    params:
      - name: pathToDockerFile
        description: The path to the dockerfile to build
        default: /workspace/docker-source/Dockerfile
      - name: pathToContext
        description:
          The build context used by Kaniko
          (https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts)
        default: /workspace/docker-source
  outputs:
    resources:
      - name: builtImage
        type: image
  steps:
    - name: build-and-push
      image: gcr.io/kaniko-project/executor
      # specifying DOCKER_CONFIG is required to allow kaniko to detect docker credential
      env:
        - name: "DOCKER_CONFIG"
          value: "/builder/home/.docker/"
      command:
        - /kaniko/executor
      args:
        - --dockerfile=${inputs.params.pathToDockerFile}
        - --destination=${outputs.resources.builtImage.url}
        - --context=${inputs.params.pathToContext}

It took me hours to figure out we have to keep the input resource name, like "docker-source" as defined in this example, in pathToDockerFile and pathToContext as part of the prefix "/workspace/docker-source", then continue the REAL path to dockerfile or context. Why is it implemented like this?
The input resource name actually has nothing to do with pathToDockerFile and pathToContext.

[imjasonh]

Resource names describe where the source is placed inside /workspace -- if you have a resource named foo and another named bar, they'll be materialized into /workspace/foo and /workspace/bar

The kaniko builder needs to be aware of the location of the input resource, to know where inside /workspace to find the Dockerfile.

FWIW, in general you should probably use the kaniko Task in the catalog, rather than creating your own.

[houshengbo]

@imjasonh Thank you for the response.
However, the kaniko task in the catalog is hardly able to use, since context is missing. I can locate the dockerfile, but it is a hassle to reach the correct directory. Probably this is a feature to be added.

[vincent-pli]

@houshengbo
You can use TargetPath to change the behavior.

[imjasonh]

The Kaniko task in the catalog sets workingdir: /workspace/source, which is supposed to address this, but since the default of --context is /workspace and not ., it doesn't. :(

I've proposed tektoncd/catalog#33 to address this, thanks for bringing this to my attention.

[houshengbo]

@imjasonh
I submitted another PR tektoncd/catalog#32 to address this already. Hope we do not repeat the effort.

--context=/workspace/source/${inputs.params.CONTEXT}, so --context can be set to ./. The user does not need to care whether workspace or workspace/source.

[dlorenc]

It looks like we can close this now that the catalog fix has been merged. Please let me know if I missed something and there is still work to do here.