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

Simplify e2e test setup #20

Open
timwis opened this issue Aug 30, 2019 · 2 comments
Open

Simplify e2e test setup #20

timwis opened this issue Aug 30, 2019 · 2 comments

Comments

@timwis
Copy link
Contributor

timwis commented Aug 30, 2019

At the moment, running e2e tests takes several steps to set it up. This is partly because cypress advises against using cypress to start your server so we can't just blow away the git repo and restart the server after each test. But once #19 is resolved we won't have to worry about making an empty commit; we'll just have to worry about creating a local repo for the test when the server starts.

@themightychris
Copy link
Member

themightychris commented Aug 30, 2019

We shouldn't need to restart the server if we're interacting with git naturally enough. See my comments in #19 but there should never be a need to blow out the repo or restart the server to test it consistently

The key is make sure any cached state the running process holds is anchored appropriately to content hashes. Don't cache what you can't hash!

Don't cache the content of refs, ever. Ask the git CLI every time (outside the same synchronous code block). When we need that to be more efficient we'll ask the disk directly. Git is brilliantly designed and built to perform really well on the back of local filesystem caching. Don't create any competing source of truth as far as what local refs resolve to, and use that when you need to cache remote refs like git does

However, anything based on content hashes you can cache the hell out of. For example, if you parse a repos table definitions, caching it under the tree hash of .gitsheets/ creates a near-perfect cache.

@themightychris
Copy link
Member

Another way to put that is that the server should be stateless with respect to ref values

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