Removes 26 tracked files that no longer describe or serve the running system, verified one by one against the whole repo (source, tests, docs, README, Makefile, Dockerfile, .gitea workflows, pyproject, packaging spec) plus dynamic-reference paths, before deletion. Root (11): one-off launch/setup write-ups from the project's first weeks that document events which never happened the way they describe — a github.com publication (the remote is self-hosted Gitea) and a 15-minute scheduler (the service runs hourly). Also .gitlab-ci.yml (unused, CI is .gitea/), .env.postgres and setup.py.backup (a placeholder env file and a backup in version control), and the PyInstaller packaging trio build_executable.py / build_simple.py / ping-river-monitor.spec, which bundled docs that no longer exist and is not how this deploys. docs (9): stale guides superseded by DATABASE_DEPLOYMENT_GUIDE, GITEA_WORKFLOWS, FLOOD_FORECASTING and DATA_SOURCES, plus two snapshots (PROJECT_STATUS, PROJECT_STRUCTURE) describing a 4-file src/ that is now 39. scripts (5): one-shot bootstrap tools already run — init_git.sh/.bat, generate_badges.py, migrate_geolocation.py, encode_password.py. Every inbound reference was fixed rather than left dangling: README doc index and migration section, three Makefile targets, the docs.yml summary step, and the GITEA_WORKFLOWS resource list. src/ is deliberately untouched. The audit proposed removing several live modules; verification showed those proposals were mis-scoped and would have broken production. .gitignore now covers the agent tooling dirs, model eval output and editor/shell leftovers — the working tree had collected 56 zero-byte files named after fragments of shell commands. 136 tests pass; production modules import clean.
8.5 KiB
🔄 Gitea Actions Workflows - Northern Thailand Ping River Monitor
📋 Overview
This document describes the Gitea Actions workflows configured for the Northern Thailand Ping River Monitor project. These workflows provide comprehensive CI/CD, security scanning, and documentation generation.
🚀 Available Workflows
1. CI/CD Pipeline (.gitea/workflows/ci.yml)
Triggers:
- Push to
mainordevelopbranches - Pull requests to
main - Daily scheduled runs at 2 AM UTC
Jobs:
- Test Suite: Multi-version Python testing (3.9-3.12)
- Code Quality: Linting, formatting, and type checking
- Build: Docker image creation and testing
- Integration Test: Testing with VictoriaMetrics service
- Deploy Staging: Automatic deployment to staging (develop branch)
- Deploy Production: Manual deployment to production (main branch)
- Performance Test: Load testing after production deployment
Key Features:
- ✅ Multi-Python version testing
- ✅ Docker multi-architecture builds (amd64, arm64)
- ✅ Service integration testing
- ✅ Automatic staging deployment
- ✅ Manual production approval
- ✅ Performance validation
2. Security & Dependency Updates (.gitea/workflows/security.yml)
Triggers:
- Daily scheduled runs at 3 AM UTC
- Manual dispatch
- Changes to requirements files or Dockerfile
Jobs:
- Dependency Scan: Safety, Bandit, Semgrep security scans
- Docker Security: Trivy vulnerability scanning
- License Check: License compliance verification
- Dependency Updates: Automated update detection
- Code Quality: Complexity and maintainability analysis
Key Features:
- 🔒 Daily security scans
- 📦 Dependency vulnerability detection
- 📄 License compliance checking
- 🔄 Automated update notifications
- 📊 Code quality metrics
3. Release Workflow (.gitea/workflows/release.yml)
Triggers:
- Git tags matching
v*.*.*pattern - Manual dispatch with version input
Jobs:
- Create Release: Automated release creation with changelog
- Test Release: Comprehensive testing across Python versions
- Build Release: Multi-architecture Docker images with proper tags
- Security Scan: Trivy security scanning of release images
- Deploy Release: Production deployment with health checks
- Validate Release: Post-deployment validation and testing
Key Features:
- 🏷️ Automated release creation
- 📝 Changelog generation
- 🐳 Multi-architecture Docker builds
- 🔒 Security scanning
- ✅ Comprehensive validation
4. Documentation (.gitea/workflows/docs.yml)
Triggers:
- Changes to documentation files
- Changes to Python source files
- Manual dispatch
Jobs:
- Validate Docs: Link checking and structure validation
- Generate API Docs: OpenAPI specification generation
- Build Sphinx Docs: Comprehensive API documentation
- Documentation Summary: Build status and artifact summary
Key Features:
- 📚 Automated API documentation
- 🔗 Link validation
- 📖 Sphinx documentation generation
- ✅ Documentation completeness checking
🔧 Workflow Configuration
Required Secrets
Configure these secrets in your Gitea repository settings:
GITEA_TOKEN # Gitea access token for container registry
GITHUB_TOKEN # GitHub personal access token for better rate limits
SLACK_WEBHOOK_URL # Optional: Slack notifications
STAGING_WEBHOOK_URL # Optional: Staging deployment webhook
PRODUCTION_WEBHOOK_URL # Optional: Production deployment webhook
Setting up GitHub Token:
- Go to GitHub → Settings → Developer settings → Personal access tokens
- Generate a new token with
public_reposcope (for public repos) orreposcope (for private repos) - Copy the token
- In your Gitea repository → Settings → Secrets → Add
GITHUB_TOKENwith the copied value
Environment Variables
Key environment variables used across workflows:
PYTHON_VERSION: '3.11' # Default Python version
REGISTRY: git.b4l.co.th # Container registry
IMAGE_NAME: grabowski/northern-thailand-ping-river-monitor
📊 Workflow Status
CI/CD Pipeline Status
- Test Coverage: Multi-version Python testing
- Code Quality: Automated linting and formatting
- Security: Integrated security scanning
- Deployment: Automated staging, manual production
Security Monitoring
- Daily Scans: Automated vulnerability detection
- Dependency Updates: Proactive update notifications
- License Compliance: Automated license checking
- Code Quality: Continuous quality monitoring
Release Management
- Automated Releases: Tag-based release creation
- Multi-Architecture: Support for amd64 and arm64
- Security Validation: Pre-deployment security checks
- Health Monitoring: Post-deployment validation
🚀 Usage Examples
Triggering Workflows
Manual CI/CD Run:
# Push to trigger CI/CD
git push origin main
# Create pull request to trigger testing
git checkout -b feature/new-feature
git push origin feature/new-feature
# Create PR in Gitea UI
Manual Security Scan:
# Trigger via Gitea Actions UI
# Go to Actions → Security & Dependency Updates → Run workflow
Creating a Release:
# Create and push a tag
git tag v3.1.1
git push origin v3.1.1
# Or use manual dispatch in Gitea Actions UI
Monitoring Workflow Results
Check Workflow Status:
- Navigate to your repository in Gitea
- Click on "Actions" tab
- View workflow runs and their status
Download Artifacts:
- Click on a completed workflow run
- Scroll to "Artifacts" section
- Download reports and logs
View Security Reports:
- Go to Security workflow runs
- Download security-reports artifacts
- Review JSON reports for vulnerabilities
🔍 Troubleshooting
Common Issues
Workflow Fails on Dependencies:
# Check requirements.txt for version conflicts
pip-compile requirements.in
Docker Build Fails:
# Test Docker build locally
make docker-build
docker run --rm ping-river-monitor python run.py --test
Security Scan Failures:
# Run security scans locally
safety check -r requirements.txt
bandit -r src/
Test Failures:
# Run tests locally
make test
python tests/test_integration.py
Debugging Workflows
Enable Debug Logging: Add to workflow file:
env:
ACTIONS_STEP_DEBUG: true
ACTIONS_RUNNER_DEBUG: true
Check Workflow Logs:
- Go to failed workflow run
- Click on failed job
- Expand failed step to see detailed logs
Validate Workflow Syntax:
# Validate YAML syntax
make validate-workflows
📈 Performance Optimization
Caching Strategy
- Pip Cache: Cached across workflow runs
- Docker Layer Cache: GitHub Actions cache for faster builds
- Dependency Cache: Cached based on requirements.txt hash
Parallel Execution
- Matrix Builds: Multiple Python versions tested in parallel
- Independent Jobs: Security scans run independently of tests
- Conditional Execution: Jobs skip when not needed
Resource Management
- Timeout Settings: Prevent hanging workflows
- Resource Limits: Appropriate runner sizing
- Artifact Cleanup: Automatic cleanup of old artifacts
🔒 Security Best Practices
Secret Management
- Use Gitea repository secrets for sensitive data
- Never commit secrets to repository
- Rotate secrets regularly
- Use least-privilege access tokens
Container Security
- Multi-stage Docker builds for smaller images
- Non-root user in containers
- Regular base image updates
- Vulnerability scanning before deployment
Code Security
- Automated security scanning in CI/CD
- Dependency vulnerability monitoring
- License compliance checking
- Code quality enforcement
📚 Additional Resources
Gitea Actions Documentation
Project-Specific Resources
Monitoring and Alerts
- Workflow status badges in README
- Email notifications for failures
- Slack/Discord integration for team updates
- Grafana dashboards for deployment metrics
Workflow Version: v3.1.3
Last Updated: 2025-08-12
Maintained By: Ping River Monitor Team