1
0
mirror of https://github.com/kellyjonbrazil/jc.git synced 2025-06-23 00:29:59 +02:00
Files
jc/CONTRIBUTING.md

90 lines
4.0 KiB
Markdown
Raw Normal View History

2021-04-02 13:19:47 -07:00
# Contributing to jc
We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Proposing a new parser
## We Develop with Github
We use github to host code, to track issues and feature requests, as well as accept pull requests.
## We Use Github Flow, So All Code Changes Happen Through Pull Requests
Pull requests are the best way to propose changes to the codebase (we use [Github Flow](https://guides.github.com/introduction/flow/index.html)). We actively welcome your pull requests:
1. Open an issue to discuss the new feature, bug fix, or parser before opening a pull request. For new parsers, it is important to agree upon a schema before developing the parser.
2. Fork the repo and create your branch from `dev`, if available, otherwise `master`.
2021-08-26 10:29:13 -07:00
3. For new parsers: Use the `jc/parsers/foo.py` parser as a [template](https://github.com/kellyjonbrazil/jc/blob/master/jc/parsers/foo.py) to get started. You can even place a new parser python module file in the [parser plugin directory](https://github.com/kellyjonbrazil/jc#custom-parsers) to get started right away with just a standard `jc` installation.
2021-08-26 10:20:53 -07:00
4. If you've added code that should be tested, add tests. All new parsers should have several sample outputs and tests.
5. Documentation is auto-generated from docstrings, so ensure they are clear and accurate.
6. Ensure the test suite passes. (Note: "**America/Los_Angeles**" timezone should be configured on the test system)
7. Make sure your code lints.
8. Issue that pull request!
2021-04-02 13:19:47 -07:00
2021-04-02 15:01:21 -07:00
## Parser Schema Guidelines
- Try to keep the schema as flat as possible - typically a list of flat dictionaries
- Keys should be lowercase, contain no special characters, and spaces should be converted to underscores
- Keys should be static, if possible. If they have to be dynamic, then they should not contain lists or dictionaries
This will make it easier to use tools like `jq` without requiring escaping of special characters, encapsulating key names in [""], keeps paths predictable, and makes iterating and searching for values easier.
**Examples**
2021-04-28 15:26:52 -07:00
Bad:
2021-04-02 15:01:21 -07:00
```
{
"Interface 1": [
192.168.1.1,
172.16.1.1
],
"Wifi Interface 1": [
2021-04-02 16:31:22 -07:00
10.1.1.1
2021-04-02 15:01:21 -07:00
]
}
```
Good:
```
[
{
"interface": "Interface 1",
"ip_addresses": [
192.168.1.1,
172.16.1.1
]
},
{
"interface": "Wifi Interface 1",
"ip_addresses": [
10.1.1.1
]
}
]
```
2021-04-24 12:47:12 -07:00
## Tests
2021-04-24 12:52:26 -07:00
It is essential to have good command output sample coverage and tests to keep the `jc` parser quality high.
2021-04-24 12:50:40 -07:00
2021-04-24 12:52:26 -07:00
Many parsers include calculated timestamp fields using the `jc.utils.timestamp` class. Naive timestamps created with this class should be generated on a system configured with the "**America/Los_Angeles**" timezone on linux/macOS/unix and "**Pacific Standard Time**" timezone on Windows for tests to pass on the Github Actions CI tests. This timezone should be configured on your local system before running the tests locally, as well.
2021-04-24 12:47:12 -07:00
2021-04-02 13:19:47 -07:00
## Any contributions you make will be under the MIT Software License
In short, when you submit code changes, your submissions are understood to be under the same [MIT License](http://choosealicense.com/licenses/mit/) that covers the project. Feel free to contact the maintainers if that's a concern.
2021-04-02 13:25:23 -07:00
## Report bugs using Github's Issues
2021-04-02 13:21:56 -07:00
We use GitHub issues to track public bugs. Report a bug by [opening a new issue](https://github.com/kellyjonbrazil/jc/issues); it's that easy!
2021-04-02 13:19:47 -07:00
## Write bug reports with detail, background, and sample code
**Great Bug Reports** tend to have:
- A quick summary and/or background
- Steps to reproduce
- Be specific!
- Give sample code if you can.
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
## Use a Consistent Coding Style
* 4 spaces for indentation rather than tabs
* Use a Python linter that will enforce PEP 8 and other best practices