# Forgejo Actions for Pricing Tests

This directory contains Forgejo Actions (Gitea Actions) workflows that automatically run pricing tests in the CI/CD pipeline. These workflows ensure that pricing calculations remain accurate and that changes to pricing logic don't introduce regressions.

## Workflow Files

### 1. `ci.yml` - Main CI/CD Pipeline
**Triggers**: Push to `main`/`develop`, Pull Requests
**Purpose**: Complete CI/CD pipeline including testing, building, and deployment

**Jobs**:
- **test**: Runs all Django tests including pricing tests
- **lint**: Code quality checks with ruff
- **security**: Security scanning with safety and bandit
- **build**: Docker image building (only on main/develop)
- **deploy**: Production deployment (only on main)

**Key Features**:
- Uses PostgreSQL service for realistic testing
- Runs pricing tests in separate groups for better visibility
- Includes Django system checks
- Only builds/deploys if tests pass

### 2. `pricing-tests.yml` - Dedicated Pricing Tests
**Triggers**: Changes to pricing-related files
**Purpose**: Comprehensive testing of pricing models and calculations

**Path Triggers**:
- `hub/services/models/pricing.py`
- `hub/services/tests/test_pricing*.py`
- `hub/services/forms.py`
- `hub/services/views/**`
- `hub/services/templates/**`

**Jobs**:
- **pricing-tests**: Matrix testing across Python and Django versions
- **pricing-documentation**: Documentation and coverage checks

**Key Features**:
- Matrix testing: Python 3.12/3.13 × Django 5.0/5.1
- Test coverage reporting
- Performance testing with large datasets
- Pricing validation with sample scenarios

### 3. `pr-pricing-validation.yml` - Pull Request Validation
**Triggers**: Pull requests affecting pricing code
**Purpose**: Validate pricing changes in PRs before merge

**Jobs**:
- **pricing-validation**: Comprehensive validation of pricing changes

**Key Features**:
- Migration detection for pricing model changes
- Coverage tracking with minimum threshold (85%)
- Critical method change detection
- Backward compatibility checking
- Test addition validation
- PR summary generation

### 4. `scheduled-pricing-tests.yml` - Scheduled Testing
**Triggers**: Daily at 6 AM UTC, manual dispatch
**Purpose**: Regular validation to catch time-based or dependency issues

**Jobs**:
- **scheduled-pricing-tests**: Matrix testing on different databases
- **notify-on-failure**: Automatic issue creation on failure

**Key Features**:
- SQLite and PostgreSQL database testing
- Stress testing with concurrent calculations
- Data integrity checks
- Daily pricing system reports
- Automatic issue creation on failures

## Environment Variables

The workflows use the following environment variables:

### Required Secrets
```yaml
REGISTRY_USERNAME      # Container registry username
REGISTRY_PASSWORD      # Container registry password
OPENSHIFT_SERVER      # OpenShift server URL
OPENSHIFT_TOKEN       # OpenShift authentication token
```

### Environment Variables
```yaml
REGISTRY              # Container registry URL
NAMESPACE            # Kubernetes namespace
DATABASE_URL         # Database connection string
DJANGO_SETTINGS_MODULE # Django settings module
```

## Workflow Triggers

### Automatic Triggers
- **Push to main/develop**: Full CI/CD pipeline
- **Pull Requests**: Pricing validation and full testing
- **File Changes**: Pricing-specific tests when pricing files change
- **Schedule**: Daily pricing validation at 6 AM UTC

### Manual Triggers
- **Workflow Dispatch**: Manual execution with options
- **Re-run**: Any workflow can be manually re-run from the Actions UI

## Test Coverage

The workflows ensure comprehensive testing of:

### Core Functionality
- ✅ Pricing model CRUD operations
- ✅ Progressive discount calculations
- ✅ Final price calculations with addons
- ✅ Multi-currency support
- ✅ Service level pricing

### Edge Cases
- ✅ Zero and negative values
- ✅ Very large calculations
- ✅ Missing data handling
- ✅ Decimal precision issues
- ✅ Database constraints

### Integration Scenarios
- ✅ Complete service setups
- ✅ Real-world pricing scenarios
- ✅ External price comparisons
- ✅ Cross-model relationships

### Performance Testing
- ✅ Large dataset calculations
- ✅ Concurrent price calculations
- ✅ Stress testing with complex discount models
- ✅ Performance regression detection

## Monitoring and Alerts

### Test Failures
- Failed tests are clearly reported in the workflow logs
- PR validation includes detailed summaries
- Scheduled tests create GitHub issues on failure

### Coverage Tracking
- Test coverage reports are generated and uploaded
- Minimum coverage threshold enforced (85%)
- Coverage trends tracked over time

### Performance Monitoring
- Performance tests ensure calculations complete within time limits
- Stress tests validate concurrent processing
- Large dataset handling verified

## Usage Examples

### Running Specific Test Categories
```bash
# Trigger pricing-specific tests
git push origin feature/pricing-changes

# Manual workflow dispatch with specific scope
# Use GitHub UI to run scheduled-pricing-tests.yml with "pricing-only" scope
```

### Viewing Results
- Check the Actions tab in your repository
- Download coverage reports from workflow artifacts
- Review PR summaries for detailed analysis

### Debugging Failures
1. Check workflow logs for detailed error messages
2. Download test artifacts for coverage reports
3. Review database-specific failures in matrix results
4. Use manual workflow dispatch to re-run with different parameters

## Best Practices

### For Developers
1. **Run Tests Locally**: Use `./run_pricing_tests.sh` before pushing
2. **Add Tests**: Include tests for new pricing features
3. **Check Coverage**: Ensure new code has adequate test coverage
4. **Performance**: Consider performance impact of pricing changes

### For Maintainers
1. **Monitor Scheduled Tests**: Review daily test results
2. **Update Dependencies**: Keep test dependencies current
3. **Adjust Thresholds**: Update coverage and performance thresholds as needed
4. **Review Failures**: Investigate and resolve test failures promptly

## Troubleshooting

### Common Issues

**Database Connection Failures**
- Check PostgreSQL service configuration
- Verify DATABASE_URL environment variable
- Ensure database is ready before tests start

**Test Timeouts**
- Increase timeout values for complex calculations
- Check for infinite loops in discount calculations
- Verify performance test thresholds

**Coverage Failures**
- Add tests for uncovered code paths
- Adjust coverage threshold if appropriate
- Check for missing test imports

**Matrix Test Failures**
- Verify compatibility across Python/Django versions
- Check for version-specific issues
- Update test configurations as needed

## Maintenance

### Regular Updates
- Update action versions (e.g., `actions/checkout@v4`)
- Update Python versions in matrix testing
- Update Django versions for compatibility testing
- Review and update test thresholds

### Monitoring
- Check scheduled test results daily
- Review coverage trends monthly
- Update documentation quarterly
- Archive old test artifacts annually

## Integration with Existing CI/CD

These Forgejo Actions complement the existing GitLab CI configuration in `.gitlab-ci.yml`. Key differences:

### GitLab CI (Existing)
- Docker image building and deployment
- Production-focused pipeline
- Simple build-test-deploy flow

### Forgejo Actions (New)
- Comprehensive testing with multiple scenarios
- Detailed pricing validation
- Matrix testing across versions
- Automated issue creation
- Coverage tracking and reporting

Both systems can coexist, with Forgejo Actions providing detailed testing and GitLab CI handling deployment.