Closed jpeach closed 4 years ago
fejta-bot
commented
4 years ago Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
bowei
commented
4 years ago /remove-lifecycle stale
fejta-bot
commented
4 years ago Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
fejta-bot
commented
4 years ago Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten
fejta-bot
commented
4 years ago Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close
k8s-ci-robot
commented
4 years ago @fejta-bot: Closing this issue.
jpeach
commented
4 years ago /reopen
we still need this
k8s-ci-robot
commented
4 years ago @jpeach: Reopened this issue.
jpeach
commented
4 years ago /reopen /lifecycle frozen
aledbf
commented
4 years ago @jpeach have you seen https://github.com/kubernetes-sigs/ingress-controller-conformance/pull/68 ?
jpeach
commented
4 years ago @jpeach have you seen #68 ?
Are you also planning to make releases of the echo server container?
aledbf
commented
4 years ago Are you also planning to make releases of the echo server container?
Yes. This is already being done after each commit in the staging bucket https://console.cloud.google.com/gcr/images/k8s-staging-ingressconformance/GLOBAL using the corresponding cloudbuild job:
The only missing task is the "release" or promotion of one particular image to the official gcr repository using the image promoter https://github.com/kubernetes-sigs/k8s-container-image-promoter This can be done using a PR in the https://github.com/kubernetes/k8s.io repository. This is an example of one promotion for ingress-nginx https://github.com/kubernetes/k8s.io/pull/1302/files
jpeach
commented
4 years ago Oh great, thanks for the pointers @aledbf!
Is your plan to tag the echo server along with the set tooling once there is a release, or would you version everything together?
aledbf
commented
4 years ago Is your plan to tag the echo server along with the set tooling once there is a release,
This. But also we could add another flag to allow custom echo server images.
aledbf
commented
4 years ago I will open a PR to publish a version of the echo server image and add a comment here
aledbf
commented
4 years ago Five minutes after https://github.com/kubernetes/k8s.io/pull/1340, the image will be available
aledbf
commented
4 years ago done k8s.gcr.io/ingressconformance/echoserver:v0.0.1@sha256:9b34b17f391f87fb2155f01da2f2f90b7a4a5c1110ed84cb5379faa4f570dc52
In order to run the the conformance suite from automated CI systems, it would be convenient to create binary release artifacts that can be downloaded and run directly from Github. A prerequisite for this would probably be using go-bindata to bundle the deployments YAML, and adding a subcommand or other logic to apply it.