|
| 1 | +# Contributing to ZAD Actions |
| 2 | + |
| 3 | +Thank you for your interest in contributing to ZAD Actions! |
| 4 | + |
| 5 | +## Development Setup |
| 6 | + |
| 7 | +### Prerequisites |
| 8 | + |
| 9 | +- Git |
| 10 | +- [pre-commit](https://pre-commit.com/) (for local linting) |
| 11 | +- [ShellCheck](https://www.shellcheck.net/) (for bash script linting) |
| 12 | +- [actionlint](https://github.com/rhysd/actionlint) (for GitHub Actions validation) |
| 13 | + |
| 14 | +### Setting Up Pre-commit Hooks |
| 15 | + |
| 16 | +```bash |
| 17 | +# Install pre-commit |
| 18 | +pip install pre-commit |
| 19 | + |
| 20 | +# Install the git hooks |
| 21 | +pre-commit install |
| 22 | + |
| 23 | +# Run hooks manually on all files |
| 24 | +pre-commit run --all-files |
| 25 | +``` |
| 26 | + |
| 27 | +## Development Workflow |
| 28 | + |
| 29 | +1. **Fork the repository** and clone your fork |
| 30 | +2. **Create a branch** for your changes: `git checkout -b feature/my-feature` |
| 31 | +3. **Make your changes** and ensure they pass linting |
| 32 | +4. **Test your changes** in a real workflow (see Testing below) |
| 33 | +5. **Commit your changes** with a clear message |
| 34 | +6. **Push and create a pull request** |
| 35 | + |
| 36 | +## Testing |
| 37 | + |
| 38 | +### Testing Locally |
| 39 | + |
| 40 | +Run the pre-commit hooks to validate your changes: |
| 41 | + |
| 42 | +```bash |
| 43 | +pre-commit run --all-files |
| 44 | +``` |
| 45 | + |
| 46 | +### Testing in a Workflow |
| 47 | + |
| 48 | +To test action changes in a real workflow: |
| 49 | + |
| 50 | +1. Push your branch to your fork |
| 51 | +2. Reference your branch in a test workflow: |
| 52 | + ```yaml |
| 53 | + - uses: your-username/zad-actions/deploy@your-branch |
| 54 | + ``` |
| 55 | +3. Verify the action works as expected |
| 56 | +
|
| 57 | +## Code Style |
| 58 | +
|
| 59 | +- **Bash scripts**: Follow [Google's Shell Style Guide](https://google.github.io/styleguide/shellguide.html) |
| 60 | +- **YAML**: Use 2-space indentation |
| 61 | +- **Input validation**: Always validate user inputs before using them |
| 62 | +- **Error handling**: Provide clear error messages |
| 63 | +
|
| 64 | +## Commit Messages |
| 65 | +
|
| 66 | +Use clear, descriptive commit messages: |
| 67 | +
|
| 68 | +- `feat: Add support for multiple components` |
| 69 | +- `fix: Handle 404 response correctly` |
| 70 | +- `docs: Update authentication documentation` |
| 71 | +- `chore: Update CI workflow` |
| 72 | + |
| 73 | +## Versioning |
| 74 | + |
| 75 | +This project uses [Semantic Versioning](https://semver.org/): |
| 76 | + |
| 77 | +- **Major** (v2.0.0): Breaking changes to action inputs/outputs |
| 78 | +- **Minor** (v1.1.0): New features, new optional inputs |
| 79 | +- **Patch** (v1.0.1): Bug fixes, documentation updates |
| 80 | + |
| 81 | +## Pull Request Process |
| 82 | + |
| 83 | +1. Update the README.md if you changed inputs/outputs |
| 84 | +2. Update action descriptions if applicable |
| 85 | +3. Ensure all CI checks pass |
| 86 | +4. Request review from a maintainer |
| 87 | + |
| 88 | +## Questions? |
| 89 | + |
| 90 | +Open an issue with the `question` label if you have questions about contributing. |
0 commit comments