|
1 | | -# Testing |
| 1 | +# Contribution Guide |
2 | 2 |
|
3 | | -Tests written in [bashunit](https://bashunit.typeddevs.com/). |
| 3 | +Thank you for your interest in contributing to our project! We welcome contributions from the community and appreciate your efforts to help improve our codebase. To ensure a smooth collaboration process, please follow the guidelines outlined below. |
| 4 | + |
| 5 | +## License |
| 6 | + |
| 7 | +By contributing to this project, you agree to maintain the MIT license for your contributions. All code and documentation submitted as part of your contributions will be subject to the terms and conditions of the MIT license. |
| 8 | + |
| 9 | +## Semantic Versioning |
| 10 | + |
| 11 | +We adhere to Semantic Versioning (SemVer) when introducing new fixes and features. When making changes that may affect the public contract or assumptions that current users might have made, we will: |
| 12 | + |
| 13 | +1. Discuss the proposed changes openly within the project's communication channels (e.g., issue threads, pull requests) before making a decision. |
| 14 | +2. If the changes are agreed upon and deemed beneficial, we will publish a new major version to indicate that the GitHub Action is no longer backward compatible in terms of the public contract or assumptions. |
| 15 | + |
| 16 | +## Code Quality |
| 17 | + |
| 18 | +To maintain a consistent and readable codebase, we kindly ask you to follow the existing code patterns and conventions. This includes: |
| 19 | + |
| 20 | +- Writing short functions with clear purpose and naming. |
| 21 | +- Separating functions by modules or namespaces (e.g., `github`, `ensure`). |
| 22 | +- Following the established coding style and best practices. |
| 23 | + |
| 24 | +While we don't aim to be overly strict, we appreciate your willingness to adhere to the existing patterns and maintain a minimum level of code quality. |
| 25 | + |
| 26 | +## Testing |
| 27 | + |
| 28 | +Tests are written using [bashunit](https://bashunit.typeddevs.com/). |
| 29 | + |
| 30 | +To install the vendor dependencies, run: |
4 | 31 |
|
5 | | -Install vendor dependencies: |
6 | 32 | ```bash |
7 | 33 | ./install-dependencies.sh |
8 | 34 | ``` |
9 | 35 |
|
10 | | -Run all tests: |
| 36 | +To run all tests, use the following command: |
| 37 | + |
11 | 38 | ```bash |
12 | 39 | ./lib/bashunit tests |
13 | 40 | ``` |
| 41 | + |
| 42 | +Please make sure to write appropriate tests for any new features or bug fixes you introduce. Tests should be placed in the `tests` directory and follow the naming convention of `test_*.sh`. |
| 43 | + |
| 44 | +## Contribution Process |
| 45 | + |
| 46 | +To contribute to this project, you can follow the common steps you would follow to contribute to any other Open Source project, that is: |
| 47 | + |
| 48 | +1. Fork the repository and create a new branch for your feature or bug fix. |
| 49 | +2. Make your changes in the new branch, ensuring that your code follows the project's coding style and conventions. |
| 50 | +3. Write clear and concise commit messages that describe the purpose of your changes. |
| 51 | +4. Update the unit tests if the change requires testing, ie not a documentation change. |
| 52 | +5. Push your changes to your forked repository. |
| 53 | +6. Submit a pull request to the main repository, clearly explaining the purpose and scope of your changes by populating the pull request template. |
| 54 | +7. Engage in the discussion and address any feedback or questions raised during the code review process. |
| 55 | + |
| 56 | +We will review your contribution and provide feedback as soon as possible. Once your changes have been approved, they will be merged into the main branch. |
| 57 | + |
| 58 | +Thank you for your contribution and support! |
0 commit comments