docs+docker: Enhanced Docker configuration and workflow fixes (#4)
* addinte templates and user guide * up docs * up * up claude.md * add mb * umb * up workflow * up settings claude * adding detailed docs * adding missing files docs * add main readme for docs * up main readme * adding docs for tests * Complete documentation integration with test structure analysis link Adds link to comprehensive test structure documentation in main README.md, finalizing the progressive disclosure strategy for project documentation. This completes the documentation integration work that includes: - Architecture documentation - API reference documentation - Contributing guidelines - Detailed test analysis 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * removing folders from git * up * up * up gitignore * feat: Add automatic semantic versioning workflow - Create GitHub Actions workflow for automatic version bumping based on PR title prefixes - Add version bumping script (scripts/bump_version.py) for programmatic updates - Update PR template with semantic versioning guidelines - Document versioning workflow in contributing guide - Integrate with existing Docker build workflow via git tags This enables automatic version management: - feat: triggers MINOR version bump - fix: triggers PATCH version bump - breaking: triggers MAJOR version bump - docs/chore/test: no version bump 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com> * fix: Separate Docker workflows for testing and publishing - Add docker-test.yml for PR validation (build test only) - Fix build_and_publish_docker.yml to trigger only on tags - Remove problematic sha prefix causing invalid tag format - Ensure proper workflow sequence: PR test → merge → version → publish 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * style: Fix black formatting issues in bump_version.py - Fix spacing and indentation to pass black formatter - Ensure code quality standards are met for CI workflow 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * style: Modernize type hints in bump_version.py - Replace typing.Tuple with modern tuple syntax - Remove deprecated typing imports per ruff suggestions - Maintain Python 3.10+ compatibility 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * fix: Remove invalid colon in bash else statement - Fix bash syntax error in auto-version workflow - Remove Python-style colon from else statement - Resolves exit code 127 in version bump determination 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * feat: Add Docker build combinations for non-versioning prefixes - Add support for prefix+docker combinations (docs+docker:, chore+docker:, etc.) - Enable Docker build for non-versioning changes when requested - Add repository_dispatch trigger for Docker workflow - Update Docker tagging for PR-based builds (pr-X, main-sha) - Update PR template with new prefix options This allows contributors to force Docker builds for documentation, maintenance, and other non-versioning changes when needed. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * docs: Add comprehensive PR prefix and automation documentation - Update CONTRIBUTING.md with detailed PR prefix system explanation - Add automation workflow documentation to docs/contributing/workflows.md - Create new user-friendly contributing guide at docs/user-guides/contributing-guide.md - Include Mermaid diagrams for workflow visualization - Document Docker testing combinations and image tagging strategy - Add best practices and common mistakes to avoid This provides clear guidance for contributors on using the automated versioning and Docker build system effectively. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * docs+docker: Complete documentation infrastructure with Docker automation testing (#2) * fix: Remove invalid colon in bash else statement - Fix bash syntax error in auto-version workflow - Remove Python-style colon from else statement - Resolves exit code 127 in version bump determination 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * feat: Add Docker build combinations for non-versioning prefixes - Add support for prefix+docker combinations (docs+docker:, chore+docker:, etc.) - Enable Docker build for non-versioning changes when requested - Add repository_dispatch trigger for Docker workflow - Update Docker tagging for PR-based builds (pr-X, main-sha) - Update PR template with new prefix options This allows contributors to force Docker builds for documentation, maintenance, and other non-versioning changes when needed. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * docs: Add comprehensive PR prefix and automation documentation - Update CONTRIBUTING.md with detailed PR prefix system explanation - Add automation workflow documentation to docs/contributing/workflows.md - Create new user-friendly contributing guide at docs/user-guides/contributing-guide.md - Include Mermaid diagrams for workflow visualization - Document Docker testing combinations and image tagging strategy - Add best practices and common mistakes to avoid This provides clear guidance for contributors on using the automated versioning and Docker build system effectively. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Patryk Ciechanski <patryk.ciechanski@inetum.com> Co-authored-by: Claude <noreply@anthropic.com> * fix: Correct digest reference in Docker artifact attestation - Add id to build step to capture outputs - Fix subject-digest reference from steps.build.outputs.digest - Resolves 'One of subject-path or subject-digest must be provided' error 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * docs: Add comprehensive Docker image usage instructions - Add Option B (Published Docker Image) to main README.md - Update installation guide with published image as fastest option - Add comprehensive configuration examples for GHCR images - Document image tagging strategy (latest, versioned, PR builds) - Include version pinning examples for stability - Highlight benefits: instant setup, no build, cross-platform Users can now choose between: 1. Published image (fastest, no setup) - ghcr.io/patrykiti/gemini-mcp-server:latest 2. Local build (development, customization) - traditional setup 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * feat: Add automated Docker image usage instructions and PR comments - Generate comprehensive usage instructions in workflow summary after Docker build - Include exact docker pull commands with built image tags - Auto-generate Claude Desktop configuration examples - Add automatic PR comments with testing instructions for +docker builds - Show expected image tags (pr-X, main-sha) in PR comments - Include ready-to-use configuration snippets for immediate testing - Link to GitHub Container Registry and Actions for monitoring Now when Docker images are built, users get: - Step-by-step usage instructions in workflow summary - PR comments with exact pull commands and config - Copy-paste ready Claude Desktop configurations - Direct links to monitor build progress 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * feat: Add automatic README.md updating after Docker builds - Updates Docker image references in README.md and documentation files - Automatically commits and pushes changes after image builds - Handles both release builds (version tags) and development builds (PR numbers) - Ensures documentation always references the latest published images - Uses sed pattern matching to update ghcr.io image references 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * correcting * up * fix: GitHub Actions workflows semantic errors Fixed critical semantic and logic errors in auto-version and Docker workflows: Auto-version.yml fixes: - Removed duplicate echo statements for should_build_docker output - Fixed malformed if/else structure (else after else) - Removed redundant conditional blocks for docker: prefixes - Cleaned up duplicate lines in summary generation Build_and_publish_docker.yml fixes: - Replaced hardcoded 'patrykiti' with dynamic ${{ github.repository_owner }} - Enhanced regex pattern to support underscores in Docker tags: [a-zA-Z0-9\._-]* - Fixed sed patterns for dynamic repository owner detection These changes ensure workflows execute correctly and support any repository owner. 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com> * docs: Add advanced Docker configuration options to README Added comprehensive configuration section with optional environment variables: Docker Configuration Features: - Advanced configuration example with all available env vars - Complete table of environment variables with descriptions - Practical examples for common configuration scenarios - Clear documentation of config.py options for Docker users Available Configuration Options: - DEFAULT_MODEL: Choose between Pro (quality) vs Flash (speed) - DEFAULT_THINKING_MODE_THINKDEEP: Control token costs with thinking depth - LOG_LEVEL: Debug logging for troubleshooting - MCP_PROJECT_ROOT: Security sandbox for file access - REDIS_URL: Custom Redis configuration Benefits: - Users can customize server behavior without rebuilding images - Better cost control through model and thinking mode selection - Enhanced security through project root restrictions - Improved debugging capabilities with configurable logging - Complete transparency of available configuration options This addresses user request for exposing config.py parameters via Docker environment variables. 🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Patryk Ciechanski <patryk.ciechanski@inetum.com> Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
200
CONTRIBUTING.md
Normal file
200
CONTRIBUTING.md
Normal file
@@ -0,0 +1,200 @@
|
||||
# Contributing to Gemini MCP Server
|
||||
|
||||
Thank you for your interest in contributing! This guide explains how to set up the development environment and contribute to the project.
|
||||
|
||||
## Development Setup
|
||||
|
||||
1. **Clone the repository**
|
||||
```bash
|
||||
git clone https://github.com/BeehiveInnovations/gemini-mcp-server.git
|
||||
cd gemini-mcp-server
|
||||
```
|
||||
|
||||
2. **Create virtual environment**
|
||||
```bash
|
||||
python -m venv venv
|
||||
source venv/bin/activate # On Windows: venv\Scripts\activate
|
||||
```
|
||||
|
||||
3. **Install dependencies**
|
||||
```bash
|
||||
pip install -r requirements.txt
|
||||
```
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
### Two Types of Tests
|
||||
|
||||
#### 1. Unit Tests (Mandatory - No API Key Required)
|
||||
- **Location**: `tests/test_*.py` (except `test_live_integration.py`)
|
||||
- **Purpose**: Test logic, mocking, and functionality without API calls
|
||||
- **Run with**: `python -m pytest tests/ --ignore=tests/test_live_integration.py -v`
|
||||
- **GitHub Actions**: ✅ Always runs
|
||||
- **Coverage**: Measures code coverage
|
||||
|
||||
#### 2. Live Integration Tests (Optional - API Key Required)
|
||||
- **Location**: `tests/test_live_integration.py`
|
||||
- **Purpose**: Verify actual API integration works
|
||||
- **Run with**: `python tests/test_live_integration.py` (requires `GEMINI_API_KEY`)
|
||||
- **GitHub Actions**: 🔒 Only runs if `GEMINI_API_KEY` secret is set
|
||||
|
||||
### Running Tests
|
||||
|
||||
```bash
|
||||
# Run all unit tests (CI-friendly, no API key needed)
|
||||
python -m pytest tests/ --ignore=tests/test_live_integration.py -v
|
||||
|
||||
# Run with coverage
|
||||
python -m pytest tests/ --ignore=tests/test_live_integration.py --cov=. --cov-report=html
|
||||
|
||||
# Run live integration tests (requires API key)
|
||||
export GEMINI_API_KEY=your-api-key-here
|
||||
python tests/test_live_integration.py
|
||||
```
|
||||
|
||||
## Code Quality
|
||||
|
||||
### Formatting and Linting
|
||||
```bash
|
||||
# Install development tools
|
||||
pip install black ruff
|
||||
|
||||
# Format code
|
||||
black .
|
||||
|
||||
# Lint code
|
||||
ruff check .
|
||||
```
|
||||
|
||||
### Pre-commit Checks
|
||||
Before submitting a PR, ensure:
|
||||
- [ ] All unit tests pass: `python -m pytest tests/ --ignore=tests/test_live_integration.py -v`
|
||||
- [ ] Code is formatted: `black --check .`
|
||||
- [ ] Code passes linting: `ruff check .`
|
||||
- [ ] Live tests work (if you have API access): `python tests/test_live_integration.py`
|
||||
|
||||
## Adding New Features
|
||||
|
||||
### Adding a New Tool
|
||||
|
||||
1. **Create tool file**: `tools/your_tool.py`
|
||||
2. **Inherit from BaseTool**: Implement all required methods
|
||||
3. **Add system prompt**: Include prompt in `prompts/tool_prompts.py`
|
||||
4. **Register tool**: Add to `TOOLS` dict in `server.py`
|
||||
5. **Write tests**: Add unit tests that use mocks
|
||||
6. **Test live**: Verify with live API calls
|
||||
|
||||
### Testing New Tools
|
||||
|
||||
```python
|
||||
# Unit test example (tools/test_your_tool.py)
|
||||
@pytest.mark.asyncio
|
||||
@patch("tools.base.BaseTool.create_model")
|
||||
async def test_your_tool(self, mock_create_model):
|
||||
mock_model = Mock()
|
||||
mock_model.generate_content.return_value = Mock(
|
||||
candidates=[Mock(content=Mock(parts=[Mock(text="Expected response")]))]
|
||||
)
|
||||
mock_create_model.return_value = mock_model
|
||||
|
||||
tool = YourTool()
|
||||
result = await tool.execute({"param": "value"})
|
||||
|
||||
assert len(result) == 1
|
||||
assert "Expected response" in result[0].text
|
||||
```
|
||||
|
||||
## CI/CD Pipeline
|
||||
|
||||
The GitHub Actions workflow:
|
||||
|
||||
1. **Unit Tests**: Run on all Python versions (3.10, 3.11, 3.12)
|
||||
2. **Linting**: Check code formatting and style
|
||||
3. **Live Tests**: Only run if `GEMINI_API_KEY` secret is available
|
||||
|
||||
### Key Features:
|
||||
- **✅ No API key required for PRs** - All contributors can run tests
|
||||
- **🔒 Live verification available** - Maintainers can verify API integration
|
||||
- **📊 Coverage reporting** - Track test coverage
|
||||
- **🐍 Multi-Python support** - Ensure compatibility
|
||||
|
||||
## Contribution Guidelines
|
||||
|
||||
### Pull Request Process
|
||||
|
||||
1. **Fork the repository**
|
||||
2. **Create a feature branch**: `git checkout -b feature/your-feature`
|
||||
3. **Make your changes**
|
||||
4. **Add/update tests**
|
||||
5. **Run tests locally**: Ensure unit tests pass
|
||||
6. **Choose appropriate PR title prefix** (see below)
|
||||
7. **Submit PR**: Include description of changes
|
||||
|
||||
### PR Title Prefixes and Automation
|
||||
|
||||
The project uses automated versioning and Docker builds based on PR title prefixes:
|
||||
|
||||
#### Version Bumping Prefixes (trigger version bump + Docker build):
|
||||
- `feat: <description>` - New features → **MINOR** version bump (1.X.0)
|
||||
- `fix: <description>` - Bug fixes → **PATCH** version bump (1.0.X)
|
||||
- `breaking: <description>` - Breaking changes → **MAJOR** version bump (X.0.0)
|
||||
- `perf: <description>` - Performance improvements → **PATCH** version bump
|
||||
- `refactor: <description>` - Code refactoring → **PATCH** version bump
|
||||
|
||||
#### Non-Version Prefixes (no version bump):
|
||||
- `docs: <description>` - Documentation only
|
||||
- `chore: <description>` - Maintenance tasks
|
||||
- `test: <description>` - Test additions/changes
|
||||
- `ci: <description>` - CI/CD changes
|
||||
- `style: <description>` - Code style changes
|
||||
|
||||
#### Docker Build Options:
|
||||
For contributors who want to test Docker builds without version bumps:
|
||||
- `docker: <description>` - Force Docker build only
|
||||
- `docs+docker: <description>` - Documentation + Docker build
|
||||
- `chore+docker: <description>` - Maintenance + Docker build
|
||||
- `test+docker: <description>` - Tests + Docker build
|
||||
- `ci+docker: <description>` - CI changes + Docker build
|
||||
- `style+docker: <description>` - Style changes + Docker build
|
||||
|
||||
#### What Happens When PR is Merged:
|
||||
|
||||
**For version bumping prefixes:**
|
||||
1. Version in `config.py` is automatically updated
|
||||
2. Git tag is created (e.g., `v1.2.0`)
|
||||
3. GitHub release is published
|
||||
4. Docker image is built and pushed to GHCR with version tag
|
||||
|
||||
**For Docker build prefixes:**
|
||||
1. Docker image is built and pushed to GHCR
|
||||
2. Image tagged with `pr-{number}` and `main-{commit-sha}`
|
||||
3. No version bump or release created
|
||||
|
||||
**For standard non-version prefixes:**
|
||||
1. Changes are merged without automation
|
||||
2. No version bump, Docker build, or release
|
||||
|
||||
### Code Standards
|
||||
|
||||
- **Follow existing patterns**: Look at existing tools for examples
|
||||
- **Add comprehensive tests**: Both unit tests (required) and live tests (recommended)
|
||||
- **Update documentation**: Update README if adding new features
|
||||
- **Use type hints**: All new code should include proper type annotations
|
||||
- **Keep it simple**: Follow SOLID principles and keep functions focused
|
||||
|
||||
### Security Considerations
|
||||
|
||||
- **Never commit API keys**: Use environment variables
|
||||
- **Validate inputs**: Always validate user inputs in tools
|
||||
- **Handle errors gracefully**: Provide meaningful error messages
|
||||
- **Follow security best practices**: Sanitize file paths, validate file access
|
||||
|
||||
## Getting Help
|
||||
|
||||
- **Issues**: Open an issue for bugs or feature requests
|
||||
- **Discussions**: Use GitHub Discussions for questions
|
||||
- **Documentation**: Check the README for usage examples
|
||||
|
||||
## License
|
||||
|
||||
By contributing, you agree that your contributions will be licensed under the MIT License.
|
||||
Reference in New Issue
Block a user