Add notes to contrib file about testing and code coverage (#4778)

This commit is contained in:
Tamika Tannis 2018-04-06 16:14:14 -07:00 committed by Maxime Beauchemin
parent 59cabe7d8f
commit 91366799d3
1 changed files with 16 additions and 10 deletions

View File

@ -61,15 +61,21 @@ meets these guidelines:
1. The pull request should include tests, either as doctests,
unit tests, or both.
2. If the pull request adds functionality, the docs should be updated
2. Run `npm run lint` and resolve all errors. Run `npm run test` and
resolve all test failures.
3. Check code coverage by running the following commands in the `assets`
directory. Run `npm run cover` to check code coverage on `.js` work, and
run `nosetests --with-coverage` to check code coverage on `.py` work. You
may have to first run `pip install nose coverage`.
4. If the pull request adds functionality, the docs should be updated
as part of the same PR. Doc string are often sufficient, make
sure to follow the sphinx compatible standards.
3. The pull request should work for Python 2.7, and ideally python 3.4+.
5. The pull request should work for Python 2.7, and ideally python 3.4+.
``from __future__ import`` will be required in every `.py` file soon.
4. Code will be reviewed by re running the unittests, flake8 and syntax
6. Code will be reviewed by re running the unittests, flake8 and syntax
should be as rigorous as the core Python project.
5. Please rebase and resolve all conflicts before submitting.
6. If you are asked to update your pull request with some changes there's
7. Please rebase and resolve all conflicts before submitting.
8. If you are asked to update your pull request with some changes there's
no need to create a new one. Push your changes to the same branch.
## Documentation
@ -421,10 +427,10 @@ https://github.com/apache/incubator-superset/pull/3013
We create a branch that goes along each minor release `0.24`
and micro releases get corresponding tags as in `0.24.0`. Git history should
never be altered in release branches.
Bug fixes and security-related patches get cherry-picked
Bug fixes and security-related patches get cherry-picked
(usually from master) as in `git cherry-pick -x {SHA}`.
Following a set of cherries being picked, a release can be pushed to
Following a set of cherries being picked, a release can be pushed to
Pypi as follows:
.. code::
@ -461,11 +467,11 @@ https://github.com/apache/incubator-superset/pull/3013
# looking the latest CHANGELOG entry for the second argument
./gen_changelog.sh 0.22.1 0.25.0
# this will overwrite the CHANGELOG.md with only the version range
# so you'll want to copy paste that on top of the previous CHANGELOG.md
# so you'll want to copy paste that on top of the previous CHANGELOG.md
# open a PR against `master`
In the future we'll start publishing release candidates for minor releases
only, but typically not for micro release.
only, but typically not for micro release.
The process will be similar to the process described above, expect the
tags will be formated `0.25.0rc1`, `0.25.0rc2`, ..., until consensus
is reached.