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

Proposal: split e2e tests into their respective repositories #26

Open
arschles opened this issue Jan 19, 2016 · 6 comments
Open

Proposal: split e2e tests into their respective repositories #26

arschles opened this issue Jan 19, 2016 · 6 comments

Comments

@arschles
Copy link
Member

For example, all the tests that use the deis CLI to run stuff against the controller, should be back in deis/workflow and the git push tests should be in deis/builder. This repository should pull all those tests together and run them in a harness.

@arschles arschles added this to the v2.0-beta1 milestone Jan 19, 2016
@arschles
Copy link
Member Author

Requesting comments/ideas @jchauncey @slack @sgoings

@arschles arschles changed the title PROPOSAL: split e2e tests into their respective repositories Proposal: split e2e tests into their respective repositories Jan 19, 2016
@arschles
Copy link
Member Author

@mboersma I know you have some PRs in flight right now, so let me know when you're done and I'll begin the split-out process

@sgoings
Copy link
Member

sgoings commented Jan 20, 2016

How would one "run all the e2e tests" after this split up?

@jchauncey
Copy link
Member

So my first thought is to do the following:

  1. individual components have a directory that contains all the necessary go code to produce a binary that can be run to fully test that component. So for example logger would have a logger_test binary (producible out of the e2e testing directory). This would allow developers to run this test against an existing kubernetes cluster by filling in a few pieces of information like the k8s api. (In a container of course)
  2. This part is still up for some debate:
    2a. We pull in all the component e2e testing directories as deps in a larger project and build all the binaries there. Package those up in a container and have a master script call each binary to run those tests.
    2b. Pull in all the deps and have a master testing binary for the full e2e suite.

@arschles
Copy link
Member Author

I agree mostly with @jchauncey. Specifically, each component can have a package called tests or similar, and ginkgo build can make a test binary from that code. We can also build a docker image around that binary for testing inside k8s as he said.

However, we can construct that code in such a way that this repository can import into a "master" binary, which we can also ginkgo build into a binary and build a docker image around that binary as well.

I hope I've explained that sufficiently It'll be fairly self explanatory after showing a prototype for a test or 2.

@Cryptophobia
Copy link

This issue was moved to teamhephy/workflow-e2e#17

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

No branches or pull requests

6 participants