Skip to content

Latest commit

 

History

History
153 lines (105 loc) · 6.03 KB

CONTRIBUTING.md

File metadata and controls

153 lines (105 loc) · 6.03 KB

How to Contribute

We're excited you're interested in contributing to Marquez! We'd love your help.

We welcome all levels of expertise from novice to experts.

If you are very new to the open source contribution:

  • Fork this repo
  • Star this repo and your own fork
  • In Issues tab, read some that interests you
  • You can talk to us directly on gitter.im (instructions to join on the project page README.md)
  • You can Follow us on twitter, https://twitter.com/MarquezProject

Further, check the Resources section at the bottom of this page.

There are plenty of ways to contribute:

We feel that a welcoming community is important and we ask that you follow the Contributor Covenant Code of Conduct in all interactions with the community.

Development

To run the entire test suite:

$ ./gradlew test

You can also run individual tests using the flag --tests:

$ ./gradlew test --tests marquez.api.DatasetResourceTest
$ ./gradlew test --tests marquez.service.DatasetServiceTest
$ ./gradlew test --tests marquez.db.DatasetDaoTest

Or run tests by category:

$ ./gradlew testUnit         # run only unit tests
$ ./gradlew testIntegration  # run only integration tests
$ ./gradlew testDataAccess   # run only data access tests

We use spotless to format our code. This ensures .java files are formatted to comply with Google Java Style. Make sure your code is formatted before pushing any changes, otherwise CI will fail:

$ ./gradlew spotlessApply

Note: To make formatting code simple, we recommend installing a plugin for your favorite IDE. We also us Lombok. Though not required, you might want to install the plugin as well.

Publish to Local Maven Repository

Use publishToMavenLocal to publish artifacts to your local maven repository:

$ ./gradlew publishToMavenLocal

Submitting a Pull Request

  1. Fork and clone the repository
  2. Make sure all tests pass locally: ./gradlew test
  3. Create a new branch: git checkout -b feature/my-cool-new-feature
  4. Make change on your cool new branch
  5. Write a test for your change
  6. Make sure .java files are formatted: ./gradlew spotlessJavaCheck
  7. Make sure to sign you work
  8. Push change to your fork and submit a pull request
  9. Work with project maintainers to get your change reviewed and merged into the main branch
  10. Delete your branch

To ensure your pull request is accepted, follow these guidelines:

Note: A pull request should generally contain only one commit (use git commit --amend and git push --force or squash existing commits into one).

Branching

  • Use a group at the beginning of your branch names

    wip      Work on a feature is still in progress
feature  Add or expand a feature
bug      Fix a bug

    For example:

    wip/my-cool-new-wip-feature
feature/my-cool-new-feature
feature/my-other-cool-new-feature
bug/my-bug-fix
bug/my-other-bug-fix

  • Choose short and descriptive branch names

  • Use dashes (-) to separate words in branch names

  • Use lowercase in branch names

Sign Your Work

The sign-off is a simple line at the end of the message for a commit. All commits needs to be signed. Your signature certifies that you wrote the patch or otherwise have the right to contribute the material (see Developer Certificate of Origin):

This is my commit message

Signed-off-by: Remedios Moscote <remedios.moscote@buendía.com>

Git has a -s command line option to append this automatically to your commit message:

$ git commit -s -m "This is my commit message"

API Docs

To bundle:

$ redoc-cli bundle spec/openapi.yml -o docs/openapi.html  --title "Marquez API Reference"

To serve:

$ redoc-cli serve spec/openapi.yml

Then browse to: http://localhost:8080

Note: To bundle or serve the API docs, please install redoc-cli.

Resources