Contributing to the Cardano node tests repository
Community contributions are highly appreciated. Below you will find a set of guidelines for contributing to this repository.
Note that these are guidelines and tips rather than rules. Use your best judgment, and feel free to propose changes to this document by opening a pull request.
How can I contribute?
Reporting an issue
Following these guidelines helps maintainers and the community understand your report, reproduce the behavior, and find related reports.
Before creating a bug report, please check this list of existing issues to see if a similar report already exists. When creating a bug report, include as many details as possible issue report).
Note: if you find a closed issue, which addresses the problems you’re experiencing, open a new issue and include a link to the closed one.
How do I submit a (good) issue report?
Explain the problem and include additional details to help maintainers reproduce the problem:
Use a clear and descriptive title so that the issue identifies the problem.
Describe the exact steps that reproduce the problem in as much detail as possible. When listing steps, don’t just say what you did but explain how you did it.
Provide specific examples. Include links to files, GitHub projects, or copy-pastable snippets used in those examples. When adding snippets to the issue, use Markdown code blocks.
Describe the behavior you observed after following the steps and point out the exact problem with this behavior.
Explain the behavior you expected to see instead and provide reasoning.
Specify cardano-node and cardano-node-tests versions you are using.
Your first code contribution
This process has several goals:
Maintain the quality of cardano-node-tests
Fix important issues
Engage the community in producing the best possible Cardano system tests
Enable a sustainable system for maintainers to review contributions
Please follow these steps to have your contribution considered by the maintainers:
Follow all instructions in the template (TO DO: to be added later)
Follow the style guides
After submitting your pull request, verify that all status checks have passed. If a status check is failing, and you believe the failure is unrelated to your change, comment on the pull request explaining why you believe it is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, we will open an issue to track that problem with our status check suite.
While the above prerequisites must be satisfied prior to the pull request review, reviewer(s) may ask you to complete additional design work, tests, or other changes before the pull request acceptance.
Git commit messages
Use the present tense (‘Add feature’ instead of ‘Added feature’)
Use the imperative mood (‘Move the cursor to…’ instead of ‘Moves the cursor to…’)
Limit the first line to 72 characters or less
Reference issues and pull requests liberally after the first line
Python style guide
pre-commit install to set up git hook scripts that will check your changes before every commit. Alternatively, run
make lint manually before pushing your changes.
Follow the Google Python style guide but note that formatting is handled automatically by Black (through
Roles and Responsibilities
We maintain a CODEOWNERS file which provides information who should review your code if it touches given projects. Note that you need to get approvals from all code owners (even though GitHub doesn’t give a way to enforce it).