Closed cpanato closed 2 months ago
/retest
Why test-infra and not a subproject-specific GCP project?
good question to @ameukam
Why test-infra and not a subproject-specific GCP project?
k8s-staging-test-infra
is currently is community-owned and used specifically to host the images maintained by SIG Testing. I don't correctly remember the specifics about why this name (early days of the migration to k8s-infra for those images) but my guess is test-infra
"helps" to easily identify where the Dockerfiles of those images are located.
test-infra doesn't seem right for testing ingress-controllers, though - we do already have k8s-staging-ingress-controller-conformance.
From as directional POV, what do we want as a project?
1) humans don't touch artifacts 2) bots and automation exclusively manage them
As such, it seems like building it in the same project that has the staging GCR is the right thing to do...
What do we do with this? Approve or try to adjust?
ping @robscott @bowei
These images had been used for Gateway API, but we actually just completed a migration away from them today (https://github.com/kubernetes-sigs/gateway-api/pull/2468). For the past several years, the only updates this repo was getting was just to update conformance images for Gateway API, so we decided to pull those into the main GW API repo and by extension k8s-staging-gateway-api
in gcr.
I think this specific project is effectively archived at this point, and I don't know of anyone regularly running these tests. I'm not sure it's worth the effort to make changes here. Instead, I do know that the conformance images used by Gateway API will likely continue to get significant usage and updates, so if there are any similar improvements we could make there, definitely let us know.
Instead, I do know that the conformance images used by Gateway API will likely continue to get significant usage and updates, so if there are any similar improvements we could make there, definitely let us know.
@robscott we can close this PR and request to archive this repo is done by sig-network ?
request to archive this repo is done by sig-network
I'm not 100% sure what to do here. We know that the Ingress API is essentially frozen and not going to change, which would suggest that these conformance tests would also not change. On the other hand, the Ingress API is not going away and archiving this repo may give the wrong message on that front. Interested in what others think here as well.
/cc @shaneutt @youngnick
I completely lost track of this, sorry
I think this PR is only to change the deprecated image; if other things need to be done to push this repo to an up-to-date state, we can do it in a follow-up. I volunteer myself to do all the required work.
@robscott @ameukam @thockin
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: cpanato, thockin
The full list of commands accepted by this bot can be found here.
The pull request process is described here
@thockin we will need to override the failing checks to get this merged.
also what is the best slack channel to talk with you about next steps for this repo?
sig-network is the right channel, but if you need specific people you probably need to name them :)
/retest
I don't know much about these checks - @robscott ?
@cpanato: The following test failed, say /retest
to rerun all failed tests or /retest-required
to rerun all mandatory failed tests:
Test name | Commit | Details | Required | Rerun command |
---|---|---|---|---|
pull-ingress-controller-conformance-gherkin | 9ab53be770088295dc9f5aad86414b3e5573c292 | link | true | /test pull-ingress-controller-conformance-gherkin |
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.
Yeah, it makes sense to me to keep this around rather than going full archive.
this is something we can skip to get this PR merged?
cc @thockin @youngnick @robscott
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the PR is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the PR is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the PR is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the PR is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close
@k8s-triage-robot: Closed this PR.
What type of PR is this? /kind cleanup
What this PR does / why we need it:
Related to https://github.com/kubernetes/k8s.io/issues/1523
/assign @ameukam @thockin @bowei
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged): Fixes #Does this PR introduce a user-facing change?: