-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Testing and CI #283
Comments
Would also be cool to do a coverage badge with coveralls.io https://coveralls.io/repos |
+1 for code coverage |
Update. Our tests take a long timeWe have the following issues
1. Some are too wasteful to run every time@chriscool suggested using an We could setup a box or two to run nightlies, though i'd prefer CI systems running as much of the tests as possible, as finding the issues BEFORE merging to master is much nicer than after. 2. Some are timing based :(We should move away from this. As we build tests for more complicated pieces of the protocol, please stay away from timing. (i'm the worst offender) 3. Travis is really slow and painfulPerhaps we can try a different CI system:
These all look good, not sure how to choose. Optimizing for:
I'd like not to waste too much time on this. I'm happy to pay for it, too, with a ceiling of $50/mo. 4. Cannot test across all archsEventually we'll need a few boxes people can run tests in (e.g. one in each arch). We could setup a linux and bsd digital ocean droplets, and use a mac mini I just bought. I dont think these will make sense for CI, but rather for nightlies, or debugging special cases. If you'd like to set this up / need to test on different archs, happy to grant access on a case-by-case basis (just pm me on irc). 5. Travis doesn't have fuseSame as 4. All these things are important. However, i dont want to waste a ton of our time on this right now, given we have more pressing things getting the alpha to ship. |
this is a hack around travis key-gen being really slow. One option would be to add the --key-bits option to daemon as well. Another option would be to find a better way to wait for the output, rather than waiting n seconds. cc @chriscool thoughts?
|
About Regarding go tests, there are a lot of:
so maybe we should run |
Yeah, i meant from the project root makefile, we can have something like this: test:
go test -test.short ./...
cd test/ && make test
test_expensive:
go test ./...
cd test/ && make test TEST_EXPENSIVE=1 or whatever |
|
Otherwise I am ok with having |
Now 'make test' will run the go tests with option -test.short and the sharness tests without any option. And 'make test_expensive' will run the go tests without any option and the sharness tests with option TEST_EXPENSIVE=1. This should help fix the first part of issue ipfs#283. License: MIT Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Codeship seems to work fine for our project. It took 2min 33 seconds to build everything and pass the tests. Here is the project (hope you can access it): |
I could invite only jbenet as his email address is easy to find. |
It doesn't hurt to have redundancy. We now (also) have a Jenkins box. https://build.protocol-dev.com When code is pushed to
|
great work on this @maybebtc and @chriscool 👏 |
http://appveyor.com seems much faster than travis-ci. Could run both.
Update: read #283 (comment) below
The text was updated successfully, but these errors were encountered: