We're excited you're interested in contributing to Marquez! We'd love your help, and there are plenty of ways to contribute:
- Give the repo a star
- Join our slack channel and leave us feedback or help with answering questions from the community
- Fix or report a bug
- Fix or improve documentation
- For newcomers, pick up a "good first issue", then send a pull request our way (see the resources section below for helpful links to get started)
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.
Your PR must be approved and merged by a committer.
To run the entire test suite:
$ ./gradlew :api:test
You can also run individual tests for a submodule using the --tests
flag:
$ ./gradlew :api:test --tests marquez.api.DatasetResourceTest
$ ./gradlew :api:test --tests marquez.service.DatasetServiceTest
$ ./gradlew :api:test --tests marquez.db.DatasetDaoTest
Or run tests by category:
$ ./gradlew :api:testUnit # run only unit tests
$ ./gradlew :api:testIntegration # run only integration tests
$ ./gradlew :api: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.
We use pre-commit
to manage git hooks:
$ brew install pre-commit
To setup the git hook scripts run:
$ pre-commit install
Use publishToMavenLocal
to publish artifacts to your local maven repository:
$ ./gradlew :api:publishToMavenLocal
Submitting a Pull Request
- Fork and clone the repository
- Make sure all tests pass locally:
./gradlew :api:test
- Create a new branch:
git checkout -b feature/my-cool-new-feature
- Make change on your cool new branch
- Write a test for your change
- Make sure
.java
files are formatted:./gradlew spotlessJavaCheck
- Make sure to sign you work
- Push change to your fork and submit a pull request
- Work with project maintainers to get your change reviewed and merged into the
main
branch - Delete your branch
To ensure your pull request is accepted, follow these guidelines:
- All changes should be accompanied by tests
- Do your best to have a well-formed commit message for your change
- Keep diffs small and self-contained
- If your change fixes a bug, please link the issue in your pull request description
- Any changes to the API reference requires regenerating the static
openapi.html
file.
Note: A pull request should generally contain only one commit (use
git commit --amend
andgit push --force
or squash existing commits into one).
-
Use a group at the beginning of your branch names
feature Add or expand a feature bug Fix a bug
For example:
feature/my-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
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.