-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
Update contributing.md #4368
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
Update contributing.md #4368
Conversation
addisonElliott
commented
Nov 21, 2017
- Detail how to clone the source code and begin testing new features or bug fixes
- Include commands for Windows and Unix for running test coverage and running tests.
Clean up some of the language in the document. Add command to run for testing on Windows
Update coverage directory
Add details about how to run test coverage
Codecov Report
@@ Coverage Diff @@
## master #4368 +/- ##
==========================================
- Coverage 92.74% 92.71% -0.04%
==========================================
Files 119 119
Lines 8438 8438
==========================================
- Hits 7826 7823 -3
- Misses 612 615 +3
Continue to review full report at Codecov.
|
* Never publish the lib folder. | ||
* Begin by reading the [Development Guide](http://docs.parseplatform.org/parse-server/guide/#development-guide) to learn how to get started running the parse-server. | ||
* Take testing seriously! Aim to increase the test coverage with every pull request. To obtain the test coverage of the project, run: | ||
* **Windows**: `npm run coverage:win` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if we should consolidate these so it's just npm run coverage
rather than one or the other for platform issues. We could keep npm run coverage:win
and just make it an alias for the former.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
problem is the env variables that are not processed properly on windows :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could modify npm run coverage
to os detect and run from there? Would be a bit more code underlying, but I don't believe we'd ever need to worry about which command to tell someone to use in the future and we probably wouldn't ever change it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would agree that consolidating into one would be great. It's unfortunate that npm doesn't support having scripts for specific OSes but oh well.
I'll give a shot at consolidating this into one script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(addressing both :win scripts)
test:win
wouldn't be required if all test
did was test - this is what test:win
does - suggest
- Remove
test
andcoverage
- Rename
test:win
totest
- this will only perform testing - Rename
coverage:win
tocoverage
and ensure works on Unix/Mac by using the correct path for jasmine that works for both platforms
Can probably shorten to
cross-env MONGODB_VERSION=${MONGODB_VERSION:=3.2.6} MONGODB_STORAGE_ENGINE=mmapv1 TESTING=1 node nyc ./node_modules/jasmine/bin/jasmine.js
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually here's what we use in another project for coverage (on Windows):
cross-env NODE_ENV=test TESTING=1 nyc jasmine
* **Windows**: `npm run coverage:win` | ||
* **Unix**: `npm run coverage` | ||
* Run the tests for the file you are working on with the following command: | ||
* **Windows**: `npm run test:win spec/MyFile.spec.js` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thing here, there are very few underlying differences.
* **Unix**: `npm test spec/MyFile.spec.js` | ||
* Run the tests for the whole project to make sure the code passes all tests. This can be done by running the test command for a single file but removing the test file argument. The results can be seen at *<PROJECT_ROOT>/coverage/lcov-report/index.html*. | ||
* Lint your code by running `npm run lint` to make sure the code is not going to be rejected by the CI. | ||
* **Do not** publish the *lib* folder. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@flovilmart what do you think of the language changes to the contributing here?
the COVERAGE_OPTION is set on the CI, so we can run the default command, and locally, you're not getting a performance hit from running |
we could even put it in a common |
What about using this package: https://www.npmjs.com/package/cross-var Similar to cross-env except it allows you to retrieve variables from Windows/Linux. |
That seems like a great solution, all from cross-env and good with windows. Can you check it out? |
It still would be nice to have a recommended setup for development, I know a few of the maintainers use VSCode, we also have Jetbrain licences for OSS projects, but I prefer VSCode in the end. |
Recommended setup sounds like a great README addition. |
Alright, so here's an update on what the exact issue with the First, cross-env actually supports replacing environmental variables on Windows. e.g. $ENV_VARIABLE will be replaced with the correct env. variable on Windows. But the issue lies elsewhere with running the test script on Windows. Test & Coverage Scripts
Error on WindowsOn Windows, the error message when running
Why the error?I'm going to omit the MONGODB_VERSION and other env variables besides COVERAGE_OPTION below to simplify this explanation. Here is the test script: On Unix, this will be replaced with an empty string by the shell before it is passed to cross-env. The actual command ran is On Windows, this is not recognized so the text SolutionsThere are some different solutions to this problem.
@flovilmart, @montymxb What are your thoughts? My preference is option 4 and finding a way to change the CI to not set the COVERAGE_OPTION. Can we set it up to just run |
You need to run tests to have the coverage, so gathering coverage is a corner case of the running the tests. Yes we can technically change everything to accommodate windows machines. But i’d Rather have something that keeps being simple. |
Is it not simple to change CI to run coverage instead of test as suggested and remove COVERAGE_OPTION? This would make package.json platform agnostic which I think can only be a good thing for open source. |
I really do think we should strive for a platform agnostic solution though, to agree with @steven-supersolid . It is a community after all 👍 . @addisonElliott option 2 and 4 both seem tangible. The first would require us to write a JS script for our tests, but it would still need args passed. As for the second option, and this is just a thought, could we simply declare a variable containing both params in the same line and run that instead? CROSS_ENV_ARGS=`$COVERAGE_OPTION jasmine`
cross-env $CROSS_ENV_ARGS If it substitutes after each line then CROSS_ENV_ARGS could work. Something I might take a look at myself just to see if it's even possible with cross-env... |
Didn’t you mention cross-var as a proper alternative to cross-env? |
I looked into cross-var as an alternative. It didn't not work either because it does something very similar to cross-env. The issue of it trying to execute a blank command still stands. |
alright i’ll Take care of the CI, and open a new PR |
@flovilmart Sounds good. Would you like me to create a PR to update the scripts to a single |
@addisonElliott I'm on it as well as integrating appveyor which proves to be a B****CH. #4377 |
@addisonElliott did you notice any issue with mongoldb-runner on your machine? Seems there's a pending issue on mongodb-runner, and it's preventing to run correctly on windows. mongodb-js/runner#81 |
Yes, I've had some weird issues with mongodb runner. I'll look at that issue and see if it applies. I had to manually start it each time I ran the tests |
ok I'm checking what's going on appveyor, our test suite is supposedly starting / stopping a mongodb. See those weird issue: https://ci.appveyor.com/project/flovilmart/parse-server/build/1.0.16 |
I'm good with those changes as they are! |
* Update CONTRIBUTING.md Clean up some of the language in the document. Add command to run for testing on Windows * Update CONTRIBUTING.md Update coverage directory * Update CONTRIBUTING.md Add details about how to run test coverage