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

Kaniko integration test should make sure the image is pushed #150

Closed
bobcatfish opened this issue Oct 12, 2018 · 0 comments
Closed

Kaniko integration test should make sure the image is pushed #150

bobcatfish opened this issue Oct 12, 2018 · 0 comments
Labels
meaty-juicy-coding-work This task is mostly about implementation!!! And docs and tests of course but that's a given

Comments

@bobcatfish
Copy link
Collaborator

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.

@bobcatfish 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
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
Projects
None yet
Development

No branches or pull requests

1 participant