Repository: beam-site Updated Branches: refs/heads/asf-site 8d92f7155 -> 369b331db
Updates contribution guide to include development and testing instructions for Python SDK. Project: http://git-wip-us.apache.org/repos/asf/beam-site/repo Commit: http://git-wip-us.apache.org/repos/asf/beam-site/commit/13e2e31f Tree: http://git-wip-us.apache.org/repos/asf/beam-site/tree/13e2e31f Diff: http://git-wip-us.apache.org/repos/asf/beam-site/diff/13e2e31f Branch: refs/heads/asf-site Commit: 13e2e31fd82c2098f659e361f23a1fa0b16e806c Parents: 8d92f71 Author: chamik...@google.com <chamik...@google.com> Authored: Thu May 25 17:12:50 2017 -0700 Committer: chamik...@google.com <chamik...@google.com> Committed: Tue May 30 16:16:56 2017 -0700 ---------------------------------------------------------------------- src/contribute/contribution-guide.md | 33 ++++++++++++++++++++++++++----- 1 file changed, 28 insertions(+), 5 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/beam-site/blob/13e2e31f/src/contribute/contribution-guide.md ---------------------------------------------------------------------- diff --git a/src/contribute/contribution-guide.md b/src/contribute/contribution-guide.md index 62ec895..efccb7f 100644 --- a/src/contribute/contribution-guide.md +++ b/src/contribute/contribution-guide.md @@ -80,8 +80,6 @@ If you do not already have a personal GitHub account, sign up [here](https://git #### Fork the repository on GitHub Go to the [Beam GitHub mirror](https://github.com/apache/beam/) and fork the repository to your own private account. This will be your private workspace for staging changes. -We recommend enabling Travis-CI continuous integration coverage on your private fork in order to easily test your changes before proposing a pull request. Go to [Travis-CI](https://travis-ci.org), log in with your GitHub account, and enable coverage for your repository. - #### Clone the repository locally You are now ready to create the development environment on your local machine. Feel free to repeat these steps on all machines that you want to use for development. @@ -98,6 +96,10 @@ Add your forked repository as an additional Git remote, where youâll push your You are now ready to start developing! +#### [Python SDK Only] Set up a virtual environemt + +We recommend setting up a virtual envioment for developing Python SDK. Please see instructions available in [Quickstart (Python)]({{ site.baseurl }}/get-started/quickstart-py/) for setting up a virtual environment. + #### [Optional] IDE Setup Depending on your preferred development environment, you may need to prepare it to develop Beam code. @@ -231,10 +233,31 @@ Then you can push your local, committed changes to your (forked) repository on G ### Testing All code should have appropriate unit testing coverage. New code should have new tests in the same contribution. Bug fixes should include a regression test to prevent the issue from reoccurring. -For contributions to the Java code, run unit tests locally via Maven. Alternatively, you can use Travis-CI. +#### Java SDK + +For contributions to the Java code, run unit tests locally via Maven. $ mvn clean verify +#### Python SDK + +For contributions to the Python code, you can use command given below to run unit tests locally. If you update any of the [cythonized](http://cython.org) files in Python SDK, you must install "cython" package before running following command to properly test your code. We recommend setting up a virtual environment before testing your code. + + $ python setup.py test + +You can use following command to run a single test method. + + $ python setup.py test -s <module>.<test class>.<test method> + +To Check for lint errors locally, install "tox" package and run following command. + + $ pip install tox + $ tox -e lint + +Beam supports running Python SDK tests using Maven. For this, navigate to root directory of your Apache Beam clone and execute following command. Currently this cannot be run from a virtual environment. + + $ mvn clean verify -pl sdks/python + ## Review Once the initial code is complete and the tests pass, itâs time to start the code review process. We review and discuss all code, no matter who authors it. Itâs a great way to build community, since you can learn from other developers, and they become familiar with your contribution. It also builds a strong project by encouraging a high quality bar and keeping code consistent throughout the project. @@ -260,7 +283,7 @@ When choosing a reviewer, think about who is the expert on the relevant code, wh ### Code Review and Revision During the code review process, donât rebase your branch or otherwise modify published commits, since this can remove existing comment history and be confusing to the reviewer. When you make a revision, always push it in a new commit. -Our GitHub mirror automatically provides pre-commit testing coverage using Jenkins and Travis-CI. Please make sure those tests pass; the contribution cannot be merged otherwise. +Our GitHub mirror automatically provides pre-commit testing coverage using Jenkins. Please make sure those tests pass; the contribution cannot be merged otherwise. ### LGTM Once the reviewer is happy with the change, theyâll respond with an LGTM (â*looks good to me!*â). At this point, the committer will take over, possibly make some additional touch ups, and merge your changes into the codebase. @@ -317,7 +340,7 @@ If you are merging a larger contribution, please make sure that the contributor For smaller contributions, however, this is not required. In this case, we rely on [clause five](http://www.apache.org/licenses/LICENSE-2.0#contributions) of the Apache License, Version 2.0, describing licensing of intentionally submitted contributions. ### Tests -Before merging, please make sure both Travis-CI and Jenkins tests pass, as visible in the GitHub pull request. Do not merge the pull request otherwise. +Before merging, please make sure that Jenkins tests pass, as visible in the GitHub pull request. Do not merge the pull request otherwise. ### Finishing touches At some point in the review process, you should take the pull request over and complete any outstanding work that is either minor, stylistic, or otherwise outside the expertise of the contributor.
