Skip to content

Latest commit

 

History

History
110 lines (69 loc) · 5.48 KB

CONTRIBUTING.md

File metadata and controls

110 lines (69 loc) · 5.48 KB
Raw

Contributing to Databricks Java SDK

We happily welcome contributions to the Databricks Java SDK. We use GitHub Issues to track community reported issues and GitHub Pull Requests for accepting changes.

Issues for new contributors

New contributors should look for the following tags when searching for a first contribution to the Databricks Java SDK code base. We strongly recommend that new contributors tackle “good first issue” projects first; this helps the contributor become familiar with the contribution workflow, and for the core devs to become acquainted with the contributor.

good first issue

Developer Certificate of Origin

To contribute to this repository, you must sign off your commits to certify that you have the right to contribute the code and that it complies with the open source license. You can easily do this by adding a "Signed-off-by" line to your commit message to certify your compliance. Please use use your real name as pseudonymous/anonymous contributions are not accepted.

Signed-off-by: Joe Smith <[email protected]>

If you set your user.name and user.email git configs, you can sign your commit automatically with git commit -s:

git commit -s -m "Your commit message"

Contribution Workflow

Code contributions—bug fixes, new development, test improvement—all follow a GitHub-centered workflow. To participate in Databricks Java SDK development, set up a GitHub account. Then:

  1. Fork the repo you plan to work on. Go to the project repo page and use the Fork button. This will create a copy of the repo, under your username. (For more details on how to fork a repository see this guide.)

  2. Clone down the repo to your local system.

    git clone [email protected]:YOUR_USER_NAME/databricks-sdk-java.git

  3. Create a new branch to hold your work.

    git checkout -b new-branch-name

  4. Work on your new code. Write and run tests.

  5. Commit your changes.

    git add -A

git commit -s -m "commit message here"

  6. Push your changes to your GitHub repo.

    git push origin branch-name

  7. Open a Pull Request (PR). Go to the original project repo on GitHub. There will be a message about your recently pushed branch, asking if you would like to open a pull request. Follow the prompts, compare across repositories, and submit the PR. This will send an email to the committers. You may want to consider sending an email to the mailing list for more visibility. (For more details, see the GitHub guide on PRs.)

Maintainers and other contributors will review your PR. Please participate in the conversation, and try to make any requested changes. Once the PR is approved, the code will be merged.

Additional git and GitHub resources:

Git documentation Git development workflow Resolving merge conflicts

Development Environment Setup

We recommend using IntelliJ to develop the Java SDK. You can download the community edition here. Once you have IntelliJ installed, open the SDK project by selecting File -> Open and selecting the databricks-sdk-java folder. Ensure that you have the Maven plugin loaded.

Contributing documentation

We welcome any contributions to improving documentation of the Databricks Java SDK. All documentation contributions should be as detailed as possible. Please note that many files of the SDK are autogenerated, including all files in the databricks-sdk-java/src/main/java/com/databricks/sdk/service directory, so manual edits to those files will be overwritten.

After adding any documentation, make sure to run the Spotless code formatting plugin, either from the Maven plugin in IntelliJ or from the command line: mvn spotless:apply.

Debugging

The Databricks Java SDK uses the SLF4J logging framework. To enable debug logging, add the following line to your log4j.properties file:

log4j.logger.com.databricks.sdk=DEBUG

Testing

  • All changes to the SDK should be covered by unit tests.
  • When applicable, new features should be covered by integration tests. Integration tests are automatically run against Databricks workspaces and accounts in AWS, Azure and GCP.
  • Integration tests should clean up after themselves. If an integration test creates a resource like a file or cluster, it should delete that resource after the test is complete.
  • Integration tests should reuse compute resources where possible.

Code conventions

  • Files should not be larger than 600 lines
  • Single function should fit to be seen on 13" screen: no more than 40 lines of code. Only exception to this rule is in *Test.java or *IT.java test suites.
  • There should be no unnecessary exports. Classes and functions should be private by default unless they are of value outside the package.