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

Easier local development #43

Open
brianberzins opened this issue Feb 10, 2020 · 4 comments
Open

Easier local development #43

brianberzins opened this issue Feb 10, 2020 · 4 comments

Comments

@brianberzins
Copy link
Collaborator

Working on #42 and running some local testing of #40 made me think more about my local development. I found a lot of quick success playing around with KinD (kubernetes in docker) https://github.com/kubernetes-sigs/kind

I know that I probably overdo local testing on pod-reaper because I want to make sure that something that is capable of killing every pod in a cluster functioning like I want. As part of that, I want to make sure that I, and anyone else, has a quick and easy way to try out changes locally without throwing potentially dangerous prototype versions out into non-local docker repositories.

@jdharmon
Copy link
Contributor

How about an option to read the local kubeconfig? Then you could run/debug pod-reaper locally.

See Authenticating outside the cluster.

@brianberzins
Copy link
Collaborator Author

@jdharmon
I've done that on other projects before, and I think it's a great idea here.
I additionally want to make it extremely easy to spin up a test cluster locally!

@jdharmon
Copy link
Contributor

jdharmon commented Mar 2, 2020

I tried to write e2e tests this weekend after reading Kubernetes End-to-end Testing for Everyone and using https://github.com/kubernetes-sigs/descheduler/blob/master/test/e2e/e2e_test.go as an example.

Their basic process is:

kind create cluster 
docker pull kubernetes/pause
kind load docker-image kubernetes/pause
kind get kubeconfig > /tmp/admin.conf
go test ./test/e2e/ -v

I ran into a bunch of issues with packages, but will try again when I have time.

@jdharmon
Copy link
Contributor

The Visual Studio Code Remote - Containers looks like it could be a good option. There is a Go demo: https://github.com/Microsoft/vscode-remote-try-go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants