kubetest2
kubetest2 copied to clipboard
kubernetes-sigs
Release
Do we have a release or beta release cut of this? Where can I download it from?
Not as of now, but we plan to cut a tagged release alongside whenever some of the kubernetes CI jobs start using the kubetest2 deployers (which are under construction).
For now you can get the latest binaries by go get sigs.k8s.io/kubetest2@latest and similarly for the deployers and testers.
@amwat any idea on timeframe? I would love an alpha release since I am having to upload a binary to gcs for one of my builds.
We still don't have all the functionality from kubetest yet which I probably want before the first release. Most likely some time in the 1.20 time frame.
Does go get latest work for you currently?
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
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
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-contributor-experience at kubernetes/community. /close
@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-contributor-experience at kubernetes/community. /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.
@amwat: Reopened this issue.
In response to this:
/reopen /remove-lifecycle rotten /lifecycle frozen
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.
Ack, I'd like to get in a few things and line up v0.1.0 with the alpha milestone of https://github.com/kubernetes/enhancements/tree/master/keps/sig-testing/2464-kubetest2-ci-migration#graduation-criteria
/cc @spiffxp @BenTheElder
it might be worth trialing with something like v0.0.1 just to exercise the mechanisms intended for use and let users start using fixed tags more easily. we can have many v0.0.Z to test it out.
I was mainly waiting on the node tester changes in https://github.com/kubernetes-sigs/kubetest2/pull/103 there's only 1 last issue to tackle in the milestone https://github.com/kubernetes-sigs/kubetest2/milestone/1
after which I'll cut a v0.1.0
Ah yes, I've fallen a bit behind on this 😅 . All the things that we were mostly waiting on are in now. Will cut a release this week.
Is this still something that's going to happen? Any reason to not cut a release?
amwat moved on and this project is understaffed, I'm currently the only active approver and I have a number of other more urgent things elsewhere
Hello @BenTheElder, it looks like there is a good time to resume discussion :) Right now it is impossible to use latest kubetest2 with ginkgo-tester and --test-package-version flag (when you need some exact test suite version, e.g. v1.22.2) due to preparation for ginkgo v2 in 0d04f94a45a4d0b885c272153efdde1b09c45f82, it seems only master branch contain such changes https://github.com/kubernetes/kubernetes/blob/303f47c0c069c80ec6d2b3879bc879924d555a8a/hack/ginkgo-e2e.sh#L175
I prepared PR to revert this changes, but it could be better to have release at least before and after such global changes (I mean ginkgo and ginkgo v2)
I’m sorry, I’ve been on vacation the past few weeks, I’m back now but I’m changing roles and will probably? step down from this project.
EDIT: #212
My advice for now is to pin the version using @commit with go get, but I agree that releases would be a good idea.
We should probably consider at least extremely lightweight releases that merely provide some named v0.0.Z tags to work with for pinning even if we don’t have release notes, version support policies, binaries etc yet.
cc @MushuEE