Move testing scripts, configurations, and utilities to this repository

Question

Move testing scripts, configurations, and utilities to this repository

yujuhong opened this issue 6 years ago · 9 comments

Is there a plan to move more testing configurations and common utilities into this repository? If not, I'd like to suggest that we do so while resolving various issues upstream, so that the information is kept in one place and up-to-date.

Some items that I think will be valuable to host here:

Some common tools in https://github.com/e2e-win/e2e-win-prow-deployment, e.g., repo-list.txt, exclude_conformance_test.txt, etc
Testing configurations/scripts/guidelines for individual cloud providers

Answer 1 · 2019-01-02T19:52:13.000Z

/cc @PatrickLang @pjh

Answer 2 · 2019-02-21T02:03:30.000Z

@yujuhong @pjh are you aware of anything missing? I think all the items listed are there now. We could still use some more guidance from cloud providers but the key code is there. I'd rather track omissions we find later as specific issues/PRs and close this one

Answer 3 · 2019-02-21T18:21:56.000Z

Does cloud-provider specific testing scripts belong to this repo? We have a simple bash script that we use for GCE. We can move the script to this repo if there are individual directories for cloud providers, and corresponding OWNERS files.

Answer 4 · 2019-02-21T18:30:42.000Z

I think a brief doc should be here, but not necessarily the code. I think it's ok to link to AKS-Engine for Azure, KOPS, KOBO or other scripts if needed rather than duplicating them here. If you need scripts to run a test pass, they can be here.

Answer 5 · 2019-02-21T22:17:56.000Z

You can see the scripts and artifacts we're depending on for our continuous testing on GCE here: https://github.com/yujuhong/gce-k8s-windows-testing. Yu-Ju mentioned the script (run-e2e.sh) that we use for kicking off the tests.

The only other thing of note that we have there is a .zip with the Windows CNI binaries - unfortunately we're still using some updated prebuilt binaries that David shared with us, since the code for them hasn't made its way into https://github.com/containernetworking/plugins/tree/master/plugins/main/windows yet. If we and others are going to have to depend on not-upstreamed CNI binaries for the foreseeable future then it might make sense to put them here.

I can't think of anything else missing at the moment.

Answer 6 · 2019-05-22T22:49:30.000Z

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

Answer 7 · 2019-06-21T23:36:08.000Z

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

Answer 8 · 2019-07-22T00:22:25.000Z

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

Answer 9 · 2019-07-22T00:22:32.000Z

@fejta-bot: Closing this issue.

In response to this:

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.