Implement working kaniko build Task

[bobcatfish]

Expected Behavior

Once we have implemented a simple hellworld Task (#59) a user should be able to define a Task that can build and push an image to a registry using Kaniko. This would mean that:

• Templating is in place that allows for the Task to use the image and registry values specified in the output image resource in the steps of the Task
• The kaniko image can be used
• Any required service account needed for pushing to the registry is available to the Task
• The source to build from is available via the GitHub resource input (Implement the github Resource type #58)

Should include:

• Expanding the docs about how to write a Task that uses an Image resource, and how to set up the service account correctly
• Test coverage, unit and also integration if possible (see Setup PR testing for build-pipeline integration tests #16)

Actual Behavior

Once #59 is complete, it will be possible to run simple helloworld Task, but it won't be possible to use inputs or outputs.

Steps to Reproduce the Problem

1. Deploy the Pipeline CRD + related CRDs to your cluster (note: should be docs on how to do this post kubebuilder)
2. Create a Resource like this (where gcr.io/some-registry is a registry that you/your service account can push to):

apiVersion: pipeline.knative.dev/v1beta1
kind: Resource
metadata:
  name: kaniko-resources
  namespace: default
spec:
  resources:
    - name: guestbook
      type: git
      params:
      - name: url
        value: github.com/kubernetes/examples
      - name: revision
        value: HEAD      
      - name: serviceAccount
        value: githubServiceAccount
    - name: guestbook-image
      type: image
      params:
        - name: url
          value: gcr.io/some-registry

3. Create a Task like this:

apiVersion: pipeline.knative.dev/v1beta1
kind: Task
metadata:
  name: build-push
  namespace: default
spec:
    inputs:
        resources:
        - name: workspace
          type: github
        params:
            - name: pathToDockerFile
              value: string
    outputs:
        resources:
        - name: imageToBuild
          type: image
    buildSpec:
      steps:
         - name: build-and-push
           image: gcr.io/kaniko-project/executor
      args:
         - --dockerfile=${DOCKERFILE}
         - --destination=${IMAGE}

(Or alternatively you can use the kaniko build template, but that would mean adding support for build templates:

    buildSpec:
        template:
            name: kaniko
            arguments:
                - name: DOCKERFILE
                  value: ${pathToDockerFile}
                - name: REGISTRY
                  value: ${registry}

4. Create a TaskRun like this:

apiVersion: pipeline.knative.dev/v1beta1
kind: TaskRun
metadata:
  name: kaniko-run-0
spec:
    taskRef:
        name: build-push
    resourceRef:
       name: kaniko-resources
    trigger:
        triggerRef:
            type: manual

5. Look at the logs from the running container (Note the best docs we have on this at the moment are some of the steps in the Build quick start) to see that the build and push was completed
6. Observe that the status of the TaskRun has been updated appropriately, e.g. see this example which contains:

• Outcomes of individual steps
• Started, Completed, and Successful conditions

7. Look at the image itself in the registry and verify that it was built and pushed

Additional Info

Blocked by #59 (helloworld task), #58 (GitHub resource)

[nader-ziada]

is the plan to delegate the execution of buildSpec to the already existing knative build controller? or how are we thinking about executing the buildSpec part?

[bobcatfish]

is the plan to delegate the execution of buildSpec to the already existing knative build controller? or how are we thinking about executing the buildSpec part?

That's a great question: + @aaron-prindle @imjasonh if you have any thoughts

I'm not sure myself. What I don't want to do is duplicate what knative/build is already doing - if we wrap knative/build, I hope we will use the Build CRD and controller however possible, otherwise I hope we will import from knative/build as needed, which might mean refactoring knative/build a bit.

@imjasonh do you have any vision for how we can morph Build to Task? Or should we start adding Task features into Build right away and deal with renaming later?

[nader-ziada]

/assign @pivotal-nader-ziada