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

Allow for images output by one Task to be used by steps of downstream Tasks #639

Open
bobcatfish opened this issue Mar 19, 2019 · 1 comment

Comments

@bobcatfish
Copy link
Collaborator

@bobcatfish bobcatfish commented Mar 19, 2019

Expected Behavior

Sometimes folks need to be able to build an image, which later they need to run as part of their CI/CD. For example, say you need an image (like we did for #632) that has:

  • gcloud
  • ko
  • golang

You might not be able to find a published and supported image that meets your exact needs, so you might need to build and publish your own. It would be great to have the option to do this as part of your CI/CD pipeline, e.g. something like:

apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: demo-pipeline
spec:
  resources:
  - name: source-repo
    type: git
  - name: ko-image
    type: image
  tasks:
  - name: build-ko-image
    taskRef:
      name: ko-image-builder
    resources:
      inputs:
      - name: workspace
        resource: source-repo
      outputs:
      - name: builtImage
        resource: ko-image
  - name: use-ko-image
    taskRef:
      name: run-ko
    resources:
      inputs:
      - name: workspace
        resource: source-repo
      - name: builtImage
        resource: web-image
        from: [build-ko-image]

Where the run-ko Task looks something like:

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: run-ko
spec:
  inputs:
    resources:
    - name: workspace
      type: git
    - name: ko-image
      type: image
  steps:
  - name: build-and-push
    image: ${inputs.resources.ko-image.url}@${inputs.resources.ko-image.digest}
    command:
       ... 

image: ${inputs.resources.ko-image.url}@${inputs.resources.ko-image.digest} would allow the Task to use an image which is actually an input resource

Actual Behavior

The only way to do this now would be to make the above Task something like:

```yaml
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: run-ko
spec:
  inputs:
    resources:
    - name: workspace
      type: git
  steps:
  - name: build-and-push
    image: my-ko-image
    command:
       ... 

And hope that `my-ko-image:latest` happens to be the one that was built by the previous Task.

# Additional Info

* https://github.com/tektoncd/pipeline/issues/216 is about adding Image outputs
bobcatfish added a commit to bobcatfish/pipeline that referenced this issue Mar 20, 2019
Instead of doing a lot of hacks to make sure we have all the tools we
need to auth + invoke ko, let's build an image that has what we need in
advance.

Eventually we should be able to build this image and refer to the built
image in our steps (tektoncd#639) but for now we'll have to hardcode it.

We may also improve this image in tektoncd#631, or decide to move away from `ko`
entirely.
bobcatfish added a commit to bobcatfish/pipeline that referenced this issue Mar 20, 2019
Instead of doing a lot of hacks to make sure we have all the tools we
need to auth + invoke ko, let's build an image that has what we need in
advance.

Eventually we should be able to build this image and refer to the built
image in our steps (tektoncd#639) but for now we'll have to hardcode it.

We may also improve this image in tektoncd#631, or decide to move away from `ko`
entirely.
bobcatfish added a commit to bobcatfish/pipeline that referenced this issue Mar 20, 2019
Instead of doing a lot of hacks to make sure we have all the tools we
need to auth + invoke ko, let's build an image that has what we need in
advance.

Eventually we should be able to build this image and refer to the built
image in our steps (tektoncd#639) but for now we'll have to hardcode it.

We may also improve this image in tektoncd#631, or decide to move away from `ko`
entirely.
bobcatfish added a commit to bobcatfish/pipeline that referenced this issue Mar 20, 2019
Instead of doing a lot of hacks to make sure we have all the tools we
need to auth + invoke ko, let's build an image that has what we need in
advance.

Eventually we should be able to build this image and refer to the built
image in our steps (tektoncd#639) but for now we'll have to hardcode it.

We may also improve this image in tektoncd#631, or decide to move away from `ko`
entirely.
bobcatfish added a commit to bobcatfish/pipeline that referenced this issue Mar 20, 2019
Instead of doing a lot of hacks to make sure we have all the tools we
need to auth + invoke ko, let's build an image that has what we need in
advance.

Eventually we should be able to build this image and refer to the built
image in our steps (tektoncd#639) but for now we'll have to hardcode it.

We may also improve this image in tektoncd#631, or decide to move away from `ko`
entirely.
tekton-robot added a commit that referenced this issue Mar 22, 2019
Instead of doing a lot of hacks to make sure we have all the tools we
need to auth + invoke ko, let's build an image that has what we need in
advance.

Eventually we should be able to build this image and refer to the built
image in our steps (#639) but for now we'll have to hardcode it.

We may also improve this image in #631, or decide to move away from `ko`
entirely.
@afrittoli

This comment has been minimized.

Copy link
Member

@afrittoli afrittoli commented Sep 10, 2019

We may want to wait on immutable resource before we tackle this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.