Skip to content

Latest commit

 

History

History
207 lines (141 loc) · 10 KB

DEVELOPER.md

File metadata and controls

207 lines (141 loc) · 10 KB
Raw

Developer documentation

This document summarizes information relevant to Registry committers and contributors. It includes information about the development processes and policies as well as the tools we use to facilitate those.

Table of Contents

Workflows

This section explains how to perform common activities such as reporting a bug or merging a pull request.

Coding Guidelines

Basic

  1. Avoid cryptic abbreviations. Single letter variable names are fine in very short methods with few variables, otherwise make them informative.
  2. Clear code is preferable to comments. When possible make your naming so good you don't need comments. When that isn't possible comments should be thought of as mandatory, write them to be read.
  3. Logging, configuration, and public APIs are our "UI". Make them pretty, consistent, and usable.
  4. Maximum line length is 130.
  5. Don't leave TODOs in the code or FIXMEs if you can help it. Don't leave println statements in the code. TODOs should be filed as JIRAs.
  6. User documentation should be considered a part of any user-facing the feature, just like unit tests. Example REST apis should've accompanaying documentation.
  7. Tests should never rely on timing in order to pass.
  8. Every unit test should leave no side effects, i.e., any test dependencies should be set during setup and clean during tear down.

Java

  1. Apache license headers. Make sure you have Apache License headers in your files.
  2. Tabs vs. spaces. We are using 4 spaces for indentation, not tabs.
  3. Blocks. All statements after if, for, while, do, … must always be encapsulated in a block with curly braces (even if the block contains one statement): for (...) { ... }
  4. No wildcard imports.
  5. No unused imports. Remove all unused imports.
  6. No raw types. Do not use raw generic types, unless strictly necessary (sometime necessary for signature matches, arrays).
  7. Suppress warnings. Add annotations to suppress warnings, if they cannot be avoided (such as “unchecked”, or “serial”).
  8. Comments. Add JavaDocs to public methods or inherit them by not adding any comments to the methods.
  9. logger instance should be upper case LOG.
  10. When in doubt refer to existing code or Java Coding Style except line breaking, which is described above.

Logging

  1. Please take the time to assess the logs when making a change to ensure that the important things are getting logged and there is no junk there.

  2. There are six levels of logging TRACE, DEBUG, INFO, WARN, ERROR, and FATAL, they should be used as follows.

    2.1 INFO is the level you should assume the software will be run in. 
 INFO messages are things which are not bad but which the user will definitely want to know about
 every time they occur.

2.2 TRACE and DEBUG are both things you turn on when something is wrong and you want to figure out 
what is going on. DEBUG should not be so fine grained that it will seriously effect the performance 
of the server. TRACE can be anything. Both DEBUG and TRACE statements should be 
wrapped in an if(logger.isDebugEnabled) if an expensive computation in the argument list of log method call.

2.3 WARN and ERROR indicate something that is bad. Use WARN if you aren't totally sure it is bad,
 and ERROR if you are.

2.4 Use FATAL only right before calling System.exit().

  3. Logging statements should be complete sentences with proper capitalization that are written to be read by a person not necessarily familiar with the source code.

  4. String appending using StringBuilders should not be used for building log messages. Formatting should be used. For ex: LOG.debug("Loaded class [{}] from jar [{}]", className, jarFile);

Contribute code

Create a pull request

Pull requests should be done against the read-only git repository at https://github.com/hortonworks/registry.

Take a look at Creating a pull request. In a nutshell you need to:

  1. Fork the Registry GitHub repository at https://github.com/hortonworks/registry/ to your personal GitHub account. See Fork a repo for detailed instructions.
  2. Commit any changes to your fork.
  3. Send a pull request to the Registry GitHub repository that you forked in step 1. If your pull request is related to an existing Github issue -- for instance, because you reported a bug report via Github issue earlier -- then prefix the title of your pull request with the corresponding Github issue number (e.g. ISSUE-123: ...).

You may want to read Syncing a fork for instructions on how to keep your fork up to date with the latest changes of the upstream Registry repository.

The format of pull request

The title of pull request must be standardized as follows:

ISSUE-XXX: Title matching exactly the title of Github issue

The text immediately following the Github issue number (ISSUE-XXX: ) must be an exact transcription of the title of Github issue, not the a summary of the contents of the patch.

If the title of Github issue does not accurately describe what the patch is addressing, the title of Github issue must be modified, and then copied to the Git commit message.

And the body of pull request is encouraged to be standardized as follows:

- An optional, bulleted (+, -, ., *), summary of the contents of 
- the patch. The goal is not to describe the contents of every file,
- but rather give a quick overview of the main functional areas 
- addressed by the patch.

A summary with the contents of the patch is optional but strongly encouraged if the patch is large and/or the Github title is not expressive enough to describe what the patch is doing. This text must be bulleted using one of the following bullet points (+, -, ., ). There must be at last a 1 space indent before the bullet char, and exactly one space between bullet char and the first letter of the text. Bullets are not optional, but required.

Merge a pull request

You can utilize merge script to merge a pull request. There're some tasks prior to use the script.

CI Build

Registry is integrated with travis CI. The status of the build for the pending pull request will be reflected in the PR itself. You must see "The Travis CI build passed" in the pull request before merging it.

Preparation

  1. Add Github mirror git repo to remote named pull-repo. You can set PR_REMOTE_NAME in system environment to use another name.
$ git remote add pull-repo https://github.com/hortonworks/registry.git
  1. Add git repo for push to remote named push-repo. You can set PUSH_REMOTE_NAME in system environment to use another name.
$ git remote add push-repo <push repository git url>

How to use merge script

All merges should be done using the dev/merge_registry_pr.py script, which squashes the pull request’s changes into one commit. The script is fairly self explanatory and walks you through steps and options interactively.

Please note that the script prompts for merger after squashed commit is made. Merger can then run the build and do the manual test before pushing, but in normal it is encouraged to see the CI build success on PR before merging the PR, so unless merger wants to do some manual tests, it is fine to do the push immediately.

After the PR is merged, in normal only the PR will be closed. You may need to handle associated issue manually.

Build the code and run the tests

Prerequisites

Make sure you have Gradle 6.7 and JDK 1.8 or higher. If you're running the Gradle wrapper script, it will download Gradle for you.

Building

The following commands must be run from the top-level directory.

./gradlew clean build

If you wish to skip the unit tests you can do this by adding -x test -x check to the command line.

If you already have Gradle installed locally and don't want to use the wrapper script, then just use gradle instead of gradlew. Note, however, that you may get unexpected results in this case.

Create a distribution (packaging)

The default build command also builds distribution packages for you.

$ ./gradlew clean build signArchives -x test -x check

The binaries will be created at:

registry-dist/build/distributions/schemaregistry-<version>.tar.gz
registry-dist/build/distributions/schemaregistry-<version>.zip

including corresponding *.asc digital signature files.

After running gradlew build signArchives you may be asked to enter your GPG/PGP credentials (once for each binary file, in fact). This happens because the packaging step will create *.asc digital signatures for all the binaries, and in the workflow above your GPG private key will be used to create those signatures.

You can verify whether the digital signatures match their corresponding files:

# Example: Verify the signature of the `.tar.gz` binary.
$ gpg --verify registry-dist/build/distributions/schemaregistry-<version>.tar.gz.asc