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

Use image outputs in examples #217

Merged
merged 1 commit into from
Nov 7, 2018

Conversation

bobcatfish
Copy link
Collaborator

While talking with @jonjohnsonjr about #216 I wanted to show him an
example of a Pipeline wherein there are Tasks that output Images
Resources, which are then used as inputs for subsequent Tasks. Our
examples Pipelines were meant to do that, but unfortunately when I
looked at them, I realized these were not actually hooked up properly.
The Tasks were not actually using the Images that were built by previous
Tasks, so I have updated them to do that.

I also discovered that the templating was incorrect (#108 - adding tests
for these examples - and #212 - making sure templated variables are
actually used - can't come quickly enough!) so I've updated that in the
examples as well.

@knative-prow-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bobcatfish

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@knative-prow-robot knative-prow-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Nov 2, 2018
@bobcatfish
Copy link
Collaborator Author

W1103 00:02:54.849] error: error validating "STDIN": error validating data: [ValidationError(CustomResourceDefinition.status): missing required field "conditions" in io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1beta1.CustomResourceDefinitionStatus, ValidationError(CustomResourceDefinition.status): missing required field "storedVersions" in io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1beta1.CustomResourceDefinitionStatus]; if you choose to ignore these errors, turn validation off with --validate=false
W1103 00:02:54.850] 2018/11/02 23:57:35 error executing "kubectl apply": exit status 1

wut

- name: deploy-bundle-test # 2. Deploy GuestBook and Redis to test cluster
taskRef:
name: deploy-with-kubectl
inputSourceBindings:
- name: workspace
- name: imageToDeploy1
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops, these should be redisImage and guestbookImage

@nader-ziada
Copy link
Member

/test pull-knative-build-pipeline-integration-tests

2 similar comments
@nader-ziada
Copy link
Member

/test pull-knative-build-pipeline-integration-tests

@bobcatfish
Copy link
Collaborator Author

/test pull-knative-build-pipeline-integration-tests

@nader-ziada
Copy link
Member

@bobcatfish everything looks fine to me in the yaml examples. but the test is failing for what seems to be an infrastructure issue

@bobcatfish
Copy link
Collaborator Author

I think there are 2 problems, 1 is an infrastructure problem, the other is that the k8s clusters were upgraded to 1.11 and I think we're running into something similar to kubevirt/kubevirt#1279

@adrcunha
Copy link
Contributor

adrcunha commented Nov 5, 2018

Since 5AM all CI flows are failing when creating a k8s cluster. I'll investigate.

@bobcatfish
Copy link
Collaborator Author

Thanks @adrcunha - looks like https://status.cloud.google.com//incident/compute/18012?_ga=2.196962540.-1744253383.1524667138 is over now, so we'll maybe be back to the 1.11 issue which I can look into:

/test pull-knative-build-pipeline-integration-tests

- "'s/image: k8s.gcr.io\/redis:e2e/image: ${inputs.resources.redisImage.url}@{inputs.resources.redisImage.digest}/' ${inputs.params.pathToFiles}"
- name: replaceGuestbookImage
image: busybox
command: ['sed']
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

feedback from @jonjohnsonjr : I'm going to at least TRY using kustomize before I resign myself to sed here :D

@bobcatfish
Copy link
Collaborator Author

Should be fixed by #226 🤞

/test pull-knative-build-pipeline-integration-tests

@@ -34,9 +34,8 @@ spec:
resources:
- name: workspace
type: git
- name: testImage
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the test is failing because the testImage here needs a type of image

@bobcatfish
Copy link
Collaborator Author

PTAL @shashwathi @pivotal-nader-ziada

Copy link
Member

@nader-ziada nader-ziada left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just a few minor comments

- '--namespace'
- '${inputs.clusters.targetCluster.namespace}'
- 'apply'
- '-c'
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this -c be -f?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whoops!

- name: url
value: https://github.com/grafeas/kritis-test
---
---
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are use cases when having tests in a separate repo is valid, for example having acceptance test that make sure products from different repos integrate and deploy properly. Anyways doesn't have to be part of our example, but it was good way to show using multiple git repos in the same task

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah i think that makes perfect sense - I'd like to go ahead with this change since https://github.com/grafeas/kritis-test doesn't exist, and it's kinda nice to have the examples use real world repos, but if you feel strongly I can leave it as is (with a comment maybe!)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m okay with your change :)

- name: cloudconfig
hostPath:
path: ${workspace}/config/gcloud
path: /workspace/config/gcloud
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the path here refers to /workspace while the volume mount int the step refers to /root

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm I think that's okay, the docs for hostPath (here) say:

HostPath represents a pre-existing file or directory on the host machine that is directly exposed to the container.

So I think what this is doing is creating a volume from a dir that exists already on the host (which was mounted into /workspace via the resource), then in volume mounts it's mounting this dir into a specific location in /root

@@ -23,5 +23,5 @@ spec:
command:
- /kaniko/executor
args:
- --dockerfile=${pathToDockerFile}
- --destination=$builtImage
- --dockerfile=${inputs.resources.pathToDockerFile}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should be inputs.params

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch!

While talking with @jonjohnsonjr about tektoncd#216 I wanted to show him an
example of a Pipeline wherein there are Tasks that output Images
Resources, which are then used as inputs for subsequent Tasks. Our
examples Pipelines were meant to do that, but unfortunately when I
looked at them, I realized these were not actually hooked up properly.
The Tasks were not actually using the Images that were built by previous
Tasks, so I have updated them to do that.

I also discovered that the templating was incorrect (#108 - adding tests
for these examples - and tektoncd#212 - making sure templated variables are
actually used - can't come quickly enough!) so I've updated that in the
examples as well.
@nader-ziada
Copy link
Member

/lgtm

@knative-prow-robot knative-prow-robot added the lgtm Indicates that a PR is ready to be merged. label Nov 7, 2018
@knative-prow-robot knative-prow-robot merged commit 7af42f1 into tektoncd:master Nov 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants