Open Sentry Web Site IN-PROGRESS
-
Home
- Topics
Contributing
You have found a bug or you have an idea for a cool new feature? Contributing code is a great way to give something back to the open source community. Before you dig right into the code there are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.
Getting started
- Make sure you have a GitHub account[1].
- Find the corresponding repository on GitHub[2].
- Submit a GitHub issue in the repository to request a change, assuming one does not already exist.
- Clearly describe the issue including steps to reproduce when it is a bug.
- Include screenshots and outputs whenever relevant.
- If known, explain what should be changed to fix the problem.
- If possible, specify how to test the new feature.
- Fork[3] and check out your forked repository.
Making changes
- Ensure your fork of the repository is up-to-date (use GitHub's fork sync feature[4], and pull to your local clone of the repository).
- Create a topic branch for your isolated work, named
feature/short-description
(the name is prefixed withfeature/
even if your change fixes a bug).- Usually you should base your branch on the
main
branch. - A good topic branch name can be the GitHub issue id (#nnn) plus a short description, e.g.
feature/issue-53-fix-https-certificate
. - If you have submitted multiple JIRA issues, try to maintain separate branches and pull requests.
- Check our branching model[5] for more details.
- Usually you should base your branch on the
- Make commits of logical units.
- Make sure your commit messages are meaningful and in the proper format. Your commit message should contain the key of the GitHub issue.
- Example:
Issue #53: Changed the implementation of the keystore
- Respect the original code style:
- Only use tabs for indentation.
- Create minimal diffs – disable On Save actions like Reformat Source Code or Organize Imports. If you feel the source code should be reformatted or refactored somehow, create a separate PR for this change first. Smaller changes are more likely to get approved by reviewers!
- Make sure you have added the necessary tests for your changes, typically in
src/test/java
. - Run all the tests with
mvn clean verify
to ensure nothing else was accidentally broken. - Build the project site with
mvn site
and verify the configured code quality reports (in the Project Reports section).
Making trivial changes
Cosmetic or trivial changes in a project, like indentation, white spaces, typos, or minor refactoring don't require creating a dedicated GitHub issue, but they must not be mixed with other significant changes: a separate commit and separate Pull Request must be submitted.
In this case, the topic branch should be named trivial/short-description
.
Submitting changes
- Push your changes to a topic branch in your fork of the repository.
- Submit a Pull Request (PR) to the corresponding repository in the
sentrysoftware
organization.- Verify Files Changed shows only your intended changes and does not include additional files or changes like white spaces, etc.
- Make sure all automatic checks are successful.
- Verify comments produced automatically by code quality automatic checks.
- When implementing additional changes after reviewers suggestions, simply commit and push such changes. Never squash or rebase commits that you have already pushed!
- Once your PR is merged (if approved), sync your forked repository[4], pull these changes to your locally cloned repository and delete your branch.
By submitting a PR to one of Sentry Software's repositories, you accept the terms of the Sentry Software Contributor License Agreement (CLA)[6].
Builds
To facilitate external contributions, automatic builds don't happen on Sentry Software's internal Jenkins server, but directly in GitHub with GitHub Actions[7].
Whenever possible, Sentry Software open-source projects must use shared workflows from the sentrysoftware/workflows[8] repository to build, deploy artifacts, and release new versions.
Java libraries
Sentry Software's open-source Java library projects are published on Maven Central. We will enforce several requirements to ensure the quality of our libraries:
- The project must publish its Maven Site (
mvn site
) with full reports as GitHub Pages:- Checkstyle[9]
- CPD[10]
- PMD[11]
- SpotBugs[12]
- Unit tests
- Javadoc
- Maven's artifact groupId must be
org.sentrysoftware.*
- License must be Apache-2.0[13] and all source files must include a header with the Apache-2.0 notice. We use
mvn license:update-file-header
to update the source file headers. - Publish the Javadoc and Source artifacts along with the main artifact
Pull Requests will trigger the maven-build.yml[14] GitHub Action workflow to make sure the project builds.
SNAPSHOT artifacts will be deployed automatically to the Maven Central Snapshot repository[15] on changes on the main
branch with the maven-central-deploy.yml[16] GitHub Action workflow.
Releases are performed with the maven-central-release.yml[17] GitHub Action workflow, which deploys the artifacts in a staging repository on Maven Central[18]. The staging repository must be released manually once validated by the testing team, which makes the artifact available on Maven Central for good. Login to https://s01.oss.sonatype.org/[19] to release the staging repository.
Happy coding! 😊