|
| 1 | +# AGENTS.md file |
| 2 | + |
| 3 | +## Python Virtual Environment (venv) |
| 4 | + |
| 5 | +The Python virtual environment for this repository is typically located in `.venv`. |
| 6 | + |
| 7 | +## Formatting |
| 8 | + |
| 9 | +Always format the code before commiting using, making sure that the Python code is properly formatted using: |
| 10 | + |
| 11 | +```bash |
| 12 | +pip install black |
| 13 | +black . |
| 14 | +``` |
| 15 | + |
| 16 | +## Testing |
| 17 | + |
| 18 | +To run the custom suite of unit test for Admin Scripts use the following sequence of commands that will install dependencies |
| 19 | +and run the appropriate test suite (last command). |
| 20 | + |
| 21 | +Try to run the unit tests whenever making changes to the codebase, before commiting new code. |
| 22 | + |
| 23 | +```bash |
| 24 | +pip install -r requirements.txt |
| 25 | +pip install -r extra.txt |
| 26 | +python setup.py test |
| 27 | +``` |
| 28 | + |
| 29 | +## Style Guide |
| 30 | + |
| 31 | +- Always update `CHANGELOG.md` according to semantic versioning, mentioning your changes in the unreleased section. |
| 32 | +- Write commit messages using [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). |
| 33 | +- Never bump the internal package version in `setup.py`. This is handled automatically by the release process. |
| 34 | +- Python files use CRLF as the line ending. |
| 35 | +- The implementation should be done in Python 2.7+ and compatible with Python 3.13. |
| 36 | +- No type annotations should exist in the `.py` files and if the exist they should isolated in th `.pyi` files. |
| 37 | +- The style should respect the black formatting. |
| 38 | +- The implementation should be done in a way that is compatible with the existing codebase. |
| 39 | +- Prefer `item not in list` over `not item in list`. |
| 40 | +- Prefer `item == None` over `item is None`. |
| 41 | +- The commenting style of the project is unique, try to keep commenting style consistent. |
| 42 | +- Use Python docstrings with the `:type:`, `:args:`, `:rtype:`, `:return:`, etc. structure and with a newline after the docstring end (`"""`). |
| 43 | + |
| 44 | +## Commit Messages |
| 45 | + |
| 46 | +This project follows [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) with the following structure: |
| 47 | + |
| 48 | +```text |
| 49 | +<type>: <description> |
| 50 | +
|
| 51 | +<body> |
| 52 | +``` |
| 53 | + |
| 54 | +### Commit Types |
| 55 | + |
| 56 | +| Type | Description | |
| 57 | +| ---------- | ------------------------------------------------------- | |
| 58 | +| `feat` | A new feature or functionality | |
| 59 | +| `fix` | A bug fix | |
| 60 | +| `docs` | Documentation only changes | |
| 61 | +| `refactor` | Code change that neither fixes a bug nor adds a feature | |
| 62 | +| `chore` | Maintenance tasks, dependency updates, build changes | |
| 63 | +| `test` | Adding or updating tests | |
| 64 | +| `version` | Version bump commits (reserved for releases) | |
| 65 | + |
| 66 | +### Guidelines |
| 67 | + |
| 68 | +- Use lowercase for the type prefix. |
| 69 | +- Use imperative mood in the description (e.g., "Add feature" not "Added feature"). |
| 70 | +- Keep the first line under 50 characters. |
| 71 | +- Reference issue/PR numbers when applicable using `(#123)` at the end. |
| 72 | +- For version releases, use the format `version: X.Y.Z`. |
| 73 | +- Add an extra newline between subject and body. |
| 74 | +- Make the body a series of bullet points about the commit. |
| 75 | +- Be descriptive always making use of the body of the message. |
| 76 | + |
| 77 | +### Examples |
| 78 | + |
| 79 | +```text |
| 80 | +feat: Add user authentication with OAuth 2.0 support (#138) |
| 81 | +fix: Resolve race condition in database connection pool |
| 82 | +docs: Add API endpoint documentation for v2 routes |
| 83 | +refactor: Extract validation logic into reusable utility module |
| 84 | +chore: Update dependencies to latest stable versions |
| 85 | +test: Add integration tests for payment processing flow |
| 86 | +version: 1.8.0 |
| 87 | +``` |
| 88 | + |
| 89 | +## Pre-Commit Checklist |
| 90 | + |
| 91 | +Before committing, ensure that the following operations items check: |
| 92 | + |
| 93 | +- [ ] Code is formatted with `black .` |
| 94 | +- [ ] Tests pass: `python setup.py test` |
| 95 | +- [ ] CHANGELOG.md is updated in [Unreleased] section |
| 96 | +- [ ] No debugging print statements or commented-out code |
| 97 | +- [ ] CRLF line endings are preserved |
| 98 | +- [ ] No type annotations in .py files (use .pyi if needed) |
| 99 | + |
| 100 | +## New Release |
| 101 | + |
| 102 | +To create a new release follow the following steps: |
| 103 | + |
| 104 | +- Make sure that both the tests pass and the code formatting are valid. |
| 105 | +- Increment (look at `CHANGELOG.md` for semver changes) the `version` value in `setup.py`. |
| 106 | +- Move all the `CHANGELOG.md` Unreleased items that have at least one non empty item the into a new section with the new version number and date, and then create new empty sub-sections (Added, Changed and Fixed) for the Unreleased section with a single empty item. |
| 107 | +- Create a commit with the following message `version: $VERSION_NUMBER`. |
| 108 | +- Push the commit. |
| 109 | +- Create a new tag with the value fo the new version number `$VERSION_NUMBER`. |
| 110 | +- Create a new release on the GitHub repo using the Markdown from the corresponding version entry in `CHANGELOG.md` as the description of the release and the version number as the title. |
| 111 | + |
| 112 | +## License |
| 113 | + |
| 114 | +Hive Administration Scripts is licensed under the [Apache License, Version 2.0](http://www.apache.org/licenses/). |
0 commit comments