-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Kaniko integration test should make sure the image is pushed #150
Labels
meaty-juicy-coding-work
This task is mostly about implementation!!! And docs and tests of course but that's a given
Comments
bobcatfish
added
the
meaty-juicy-coding-work
This task is mostly about implementation!!! And docs and tests of course but that's a given
label
Oct 12, 2018
tanner-bruce
pushed a commit
to tanner-bruce/build-pipeline
that referenced
this issue
Oct 16, 2018
Adds `github.com/google/go-containerregistry` as a dependency for accessing container registries Adds `KANIKO_SECRET_CONFIG_FILE` for adding a service account to the kaniko task when running e2e test locally. Fixes tektoncd#150
tanner-bruce
pushed a commit
to tanner-bruce/build-pipeline
that referenced
this issue
Oct 16, 2018
Adds `github.com/google/go-containerregistry` as a dependency for accessing container registries Adds `KANIKO_SECRET_CONFIG_FILE` for adding a service account to the kaniko task when running e2e test locally. Fixes tektoncd#150
tanner-bruce
pushed a commit
to tanner-bruce/build-pipeline
that referenced
this issue
Oct 16, 2018
Adds `github.com/google/go-containerregistry` as a dependency for accessing container registries Adds `KANIKO_SECRET_CONFIG_FILE` for adding a service account to the kaniko task when running e2e test locally. Fixes tektoncd#150
tanner-bruce
pushed a commit
to tanner-bruce/build-pipeline
that referenced
this issue
Oct 16, 2018
Adds `github.com/google/go-containerregistry` as a dependency for accessing container registries Adds `KANIKO_SECRET_CONFIG_FILE` for adding a service account to the kaniko task when running e2e test locally to ensure kaniko is able to push to a gcr.io registry.. This is necessary for running the e2e tests locally unless the kubernetes nodes provide another way of authenticating to the registry, such as provisioning them with a storage admin scope. Once tektoncd#151 is in place, we will be able to update this code to create a service account and use that in the BuildSpec. Fixes tektoncd#150
bobcatfish
added a commit
to bobcatfish/serving
that referenced
this issue
Oct 16, 2018
The DEVELOPMENT.md in knative/serving referred to a doc on setting up a kubernetes cluster (either in GKE or with minikube) which had fallen out of date with very similar installation docs in knative/docs. I ran into this when trying to figure out the correct scopes to use for creating a cluster which could pass the knative/build-pipeline kaniko integration test (tektoncd/pipeline#150) and it turned out that the `--scopes` in the doc referenced in this repo are different from the `--scopes` in the knative/docs repo.(I worked around my problem my using `storage-full`, which isn't used in either set of docs but that's a different story!)
bobcatfish
added a commit
to bobcatfish/serving
that referenced
this issue
Oct 16, 2018
The DEVELOPMENT.md in knative/serving referred to a doc on setting up a kubernetes cluster (either in GKE or with minikube) which had fallen out of date with very similar installation docs in knative/docs. I ran into this when trying to figure out the correct scopes to use for creating a cluster which could pass the knative/build-pipeline kaniko integration test (tektoncd/pipeline#150) and it turned out that the `--scopes` in the doc referenced in this repo are different from the `--scopes` in the knative/docs repo.(I worked around my problem my using `storage-full`, which isn't used in either set of docs but that's a different story!) The minikube docs that were in this repo also contained args for specifying the location of the cluster CA certs, but I'm assuming this is no longer needed since knative/docs doesn't have this and kubernetes/minikube#1647 is resolved.
bobcatfish
added a commit
to bobcatfish/serving
that referenced
this issue
Oct 16, 2018
The DEVELOPMENT.md in knative/serving referred to a doc on setting up a kubernetes cluster (either in GKE or with minikube) which had fallen out of date with very similar installation docs in knative/docs. I ran into this when trying to figure out the correct scopes to use for creating a cluster which could pass the knative/build-pipeline kaniko integration test (tektoncd/pipeline#150) and it turned out that the `--scopes` in the doc referenced in this repo are different from the `--scopes` in the knative/docs repo.(I worked around my problem my using `storage-full`, which isn't used in either set of docs but that's a different story!) The minikube docs that were in this repo also contained args for specifying the location of the cluster CA certs, but I'm assuming this is no longer needed since knative/docs doesn't have this and kubernetes/minikube#1647 is resolved.
tanner-bruce
pushed a commit
to tanner-bruce/build-pipeline
that referenced
this issue
Oct 17, 2018
Adds `github.com/google/go-containerregistry` as a dependency for accessing container registries Adds `KANIKO_SECRET_CONFIG_FILE` for adding a service account to the kaniko task when running e2e test locally to ensure kaniko is able to push to a gcr.io registry.. This is necessary for running the e2e tests locally unless the kubernetes nodes provide another way of authenticating to the registry, such as provisioning them with a storage admin scope. Once tektoncd#151 is in place, we will be able to update this code to create a service account and use that in the BuildSpec. Fixes tektoncd#150
knative-prow-robot
pushed a commit
that referenced
this issue
Oct 17, 2018
Adds `github.com/google/go-containerregistry` as a dependency for accessing container registries Adds `KANIKO_SECRET_CONFIG_FILE` for adding a service account to the kaniko task when running e2e test locally to ensure kaniko is able to push to a gcr.io registry.. This is necessary for running the e2e tests locally unless the kubernetes nodes provide another way of authenticating to the registry, such as provisioning them with a storage admin scope. Once #151 is in place, we will be able to update this code to create a service account and use that in the BuildSpec. Fixes #150
bobcatfish
added a commit
to bobcatfish/serving
that referenced
this issue
Nov 6, 2018
The DEVELOPMENT.md in knative/serving referred to a doc on setting up a kubernetes cluster (either in GKE or with minikube) which had fallen out of date with very similar installation docs in knative/docs. I ran into this when trying to figure out the correct scopes to use for creating a cluster which could pass the knative/build-pipeline kaniko integration test (tektoncd/pipeline#150) and it turned out that the `--scopes` in the doc referenced in this repo are different from the `--scopes` in the knative/docs repo.(I worked around my problem my using `storage-full`, which isn't used in either set of docs but that's a different story!) The minikube docs that were in this repo also contained args for specifying the location of the cluster CA certs, but I'm assuming this is no longer needed since knative/docs doesn't have this and kubernetes/minikube#1647 is resolved.
bobcatfish
added a commit
to bobcatfish/serving
that referenced
this issue
Nov 6, 2018
The DEVELOPMENT.md in knative/serving referred to a doc on setting up a kubernetes cluster (either in GKE or with minikube) which had fallen out of date with very similar installation docs in knative/docs. I ran into this when trying to figure out the correct scopes to use for creating a cluster which could pass the knative/build-pipeline kaniko integration test (tektoncd/pipeline#150) and it turned out that the `--scopes` in the doc referenced in this repo are different from the `--scopes` in the knative/docs repo.(I worked around my problem my using `storage-full`, which isn't used in either set of docs but that's a different story!) The minikube docs that were in this repo also contained args for specifying the location of the cluster CA certs, but I'm assuming this is no longer needed since knative/docs doesn't have this and kubernetes/minikube#1647 is resolved.
knative-prow-robot
pushed a commit
to knative/serving
that referenced
this issue
Nov 6, 2018
* Refer to knative/docs cluster setup instead of duplicating The DEVELOPMENT.md in knative/serving referred to a doc on setting up a kubernetes cluster (either in GKE or with minikube) which had fallen out of date with very similar installation docs in knative/docs. I ran into this when trying to figure out the correct scopes to use for creating a cluster which could pass the knative/build-pipeline kaniko integration test (tektoncd/pipeline#150) and it turned out that the `--scopes` in the doc referenced in this repo are different from the `--scopes` in the knative/docs repo.(I worked around my problem my using `storage-full`, which isn't used in either set of docs but that's a different story!) The minikube docs that were in this repo also contained args for specifying the location of the cluster CA certs, but I'm assuming this is no longer needed since knative/docs doesn't have this and kubernetes/minikube#1647 is resolved. * Fix paren and K8S_USER_OVERRIDE docs `K8S_USER_OVERRIDE` is only needed to run the command to setup your current user as a cluster admin, so it isn't needed as part of the general environment setup. Updated the DEVELOPMENT.md to explain that the values for this are different if you're using a GKE cluster vs a minikube cluster.
vdemeester
referenced
this issue
in vdemeester/tektoncd-pipeline
Oct 7, 2019
Use ubi-minmal for docker images
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
meaty-juicy-coding-work
This task is mostly about implementation!!! And docs and tests of course but that's a given
Expected Behavior
When the kaniko integration test succeeds, we should be confident that that means that we can push to a registry from a TaskRun, i.e. the test should actually check that the image was pushed to the registry.
Actual Behavior
The kaniko integration test currently just checks that we get
Build Successful
in the logs.The text was updated successfully, but these errors were encountered: