Local CI Scripts Guide
Overview
The GridBuilding project uses local CI scripts instead of cloud-based CI/CD. This gives developers full control over their testing and validation environment without dependency on external services.
Quick Start
| |
Scripts
ci-all.sh - Complete CI Pipeline
Orchestrates all CI checks in the proper order:
- Build
- Test
- Code Quality
Usage:
| |
Output:
- Color-coded progress indicators
- Step-by-step execution status
- Total duration and summary
- Exits with error code 1 if any step fails
ci-build.sh - Build Automation
Restores dependencies and builds the entire solution.
Usage:
| |
Features:
- Automatic dependency restoration
- Configurable build configuration
- Clear error reporting
- Fast feedback on compilation errors
ci-test.sh - Test Automation
Runs all Core tests with optional code coverage collection.
Usage:
| |
Features:
- Runs all Core unit tests (xUnit)
- Optional code coverage collection
- Godot test support (when GODOT_BIN is set)
- Detailed test output
- Coverage file locations reported
Environment Variables:
CONFIGURATION- Build configuration (default: Release)COVERAGE- Enable coverage collection (default: true)GENERATE_COVERAGE_REPORT- Iftrue, attempts to generate a local HTML/text report (default: false)GODOT_BIN- Path to Godot executable (optional)CI_ALL_BUILD_DONE- Iftrue,ci-test.shwill pass--no-buildtodotnet test(used byci-all.shto avoid redundant rebuilding)
Coverage Gates (Production-Readiness):
GATE_MODE- Coverage gate mode:pr,rc, orprod(default:pr).CS_COVERAGE_GATE- Iftrue, enforce the C# coverage gate using the generatedcoverage.opencover.xml(default:true).GDUNIT_51- Iftrue, run the 5.1 GDScript test suite viaGodotToolkit.TestOrchestrator(default:false).REACHABILITY_GATE- Iftrue, run reachability coverage (coverage-only) and validate against the committed baseline (default:true, only evaluated whenGDUNIT_51=true).
Integrity Gates:
ci-test.shvalidates csproj integrity and fails if any project attempts to hide tests via<Compile Remove="Tests/**" ...>.
ci-quality.sh - Code Quality Checks
Performs comprehensive code quality and security checks.
Usage:
| |
Checks Performed:
- Project structure validation
- Build warning detection
- Vulnerable package scanning
- Outdated package detection
- Code formatting verification (if dotnet-format installed)
Features:
- Project validation using validate-projects.sh
- Security vulnerability detection
- Warning and error counting
- Informational checks for outdated packages
- Optional code formatting verification
Exit Codes:
0- All checks passed1- Critical errors found0(with warnings) - Passed with warnings
Environment Variables
All scripts support the following environment variables:
| Variable | Default | Description |
|---|---|---|
CONFIGURATION | Release | Build configuration (Debug/Release) |
COVERAGE | true | Enable code coverage collection |
GODOT_BIN | (none) | Path to Godot executable |
Additional variables used by coverage/integrity gates are described in the ci-test.sh section.
Examples:
| |
Integration
Pre-commit Hook
Add a pre-commit hook to run CI checks:
| |
IDE Integration
VS Code
Add tasks to .vscode/tasks.json:
| |
JetBrains Rider
Add external tools via Settings → Tools → External Tools
CI/CD Integration
For automated build systems (Jenkins, GitLab CI, etc.):
| |
Troubleshooting
Build Fails
Issue: Build fails with dependency errors
Solution: Clean and restore
| |
Tests Fail
Issue: Tests fail unexpectedly
Solution: Run with detailed output
| |
Coverage Not Working
Issue: Coverage files not generated
Solution: Ensure coverlet is installed
| |
Godot Tests Skip
Issue: Godot tests always skipped
Solution: Set GODOT_BIN environment variable
| |
Quality Checks Fail
Issue: validate-projects.sh fails
Solution: Check for forbidden patterns
| |
Permission Denied
Issue: Scripts won’t execute
Solution: Make scripts executable
| |
Best Practices
Daily Development
| |
Before Pull Request
| |
Release Preparation
| |
Advantages of Local CI
- No External Dependencies: Runs completely offline
- Faster Feedback: No queue times or network delays
- Full Control: Configure and customize as needed
- Consistent Environment: Same results locally and in CI
- Easy Debugging: Direct access to logs and state
- Cost Effective: No CI/CD service costs
Future Enhancements
Potential improvements to consider:
- Parallel test execution
- Incremental builds
- Test result caching
- Docker containerization
- Performance benchmarking
- Automated changelog generation
Related Documentation
- GitHub SWE Setup Guide - Complete setup and usage
- Production Roadmap - Production timeline
- Test Isolation Workflow - Test development
Last Updated: December 8, 2024
Maintained By: Development Team
Status: Active
For questions or issues with CI scripts, please open a GitHub issue.