Welcome and thank you for considering contributing to the Checkmarx One CLI
Reading and following these guidelines will help us make the contribution process easy and effective for everyone involved. It also communicates that you agree to respect the time of the developers managing and developing these open source projects. In return, we will reciprocate that respect by addressing your issue, assessing changes, and helping you finalize your pull requests.
By participating and contributing to any Checkmarx projects, you agree to uphold our Code of Conduct.
If you have suggestions for how this project could be improved, or want to report a bug, open an issue. We appreciate all contributions. If you have questions, we'd love to hear them.
We also appreciate PRs. If you're thinking of submitting any PR, pleae open an issue first to spark a discussion around it.
Contributions are made to this repo via Issues and Pull Requests (PRs). A few general guidelines that cover both:
- Search for existing Issues and PRs before creating your own to avoid duplicates.
- PRs will only be accepted if associated with an issue (enhancement or bug) that has been submitted and reviewed/labeld as accepted by a Checkmarx team member.
- We will work hard to makes sure issues that are raised are handled in a timely manner.
Issues should be used to report problems with the solution / source code, request a new feature, or to discuss potential changes before a PR is created. When you create a new Issue, a template will be loaded that will guide you through collecting and providing the information we need to investigate.
If you find an Issue that addresses the problem you're having, please add your own reproduction information to the existing issue rather than creating a new one. Adding a reaction can also help by indicating to our maintainers that a particular problem is affecting more than just the reporter.
The following templates will be used within Checkmarx github repositories
PRs to our source are always welcome and can be a quick way to get your fix or improvement slated for the next release. In general, PRs should:
- Only fix/add the functionality in question or address code style issues, not both.
- Ensure all necessary details are provided and adhered to
- Add unit or integration tests for fixed or changed functionality (if a test suite already exists) or specify steps taken to ensure changes were tested and functionality works as expected.
- Address a single concern in the least number of changed lines as possible.
- Include documentation in the repo or Provide additional comments in Markdown comments that should be pulled/reflected in GitHub Wiki for the given project.
- Be accompanied by a complete Pull Request template (loaded automatically when a PR is created).
For changes that address core functionality or would require breaking changes (e.g. a major release), please open an Issue to discuss your proposal first.
In general, we follow the fork-and-pull Git workflow
- Fork the repository to your own Github account
- Clone the project to your machine
- Create a branch locally with a succinct but descriptive name (prefix with feature/<issue#>-descriptive-name> or hotfix/<issue#>-descriptive-name)
- Commit changes to the branch
- Push changes to your fork
- Open a PR in our repository and follow the PR template so that we can efficiently review and asses the changes. * Ensure an associated Issue has been accepted by the Checkmarx team.*
The following template will be used within Checkmarx github repositories