6dd7798cbf
fix(ci): Simplify commit message to avoid YAML parsing issues
2026-01-18 14:48:44 -05:00
b33b8a89af
fix(ci): Use heredoc for multi-line commit message in perf-report
2026-01-18 14:45:02 -05:00
3c5f1240be
fix(ci): Use deploy key instead of token for pushing
...
Deploy key is:
- Permanent (no expiration)
- Repo-scoped (no API access)
- SSH-based (more secure)
Setup: Add DEPLOY_KEY variable with base64-encoded SSH private key
Generate: ssh-keygen -t ed25519 -C 'ci@un-inception'
Encode: base64 -w0 < id_ed25519 | pbcopy
2026-01-18 14:15:07 -05:00
9ecc93a75f
fix(ci): Make perf-report job safer and more robust
...
- Add input validation for tag format
- Check for required tools (curl, jq, bc)
- Skip if report already exists (idempotent)
- Add colored logging for better visibility
- Handle push failures gracefully
- Use 'rules' instead of 'only' for modern GitLab CI
- Add GIT_DEPTH: 0 for full history access
2026-01-18 14:12:53 -05:00
88a3a6718c
feat: Add performance charts and CI auto-commit
...
- Add scripts/generate-perf-charts.py for matplotlib visualizations
- Update generate-perf-report.sh for versioned directories (reports/TAG/)
- Add make perf-charts and make perf-all targets
- Add GitLab CI perf-report job to auto-commit after tagged releases
- Generated 6 charts for 4.2.0: dashboard, duration, histogram, leaders, etc.
Each release now gets its own reports/TAG/ directory with:
- perf.json (raw timing data)
- perf.md (markdown report)
- chart-*.png (6 visualizations)
2026-01-18 14:00:08 -05:00
c8502316be
fix(ci): Accept tags without v prefix (4.2.0 instead of v4.2.0)
2026-01-17 18:13:12 -05:00
f46d8cd556
fix(ci): Use child pipeline trigger for test matrix
...
- Child pipeline gets generated test-matrix.yml from artifact
- Each of 42 languages runs as parallel job
- Child pipeline builds its own C CLI
2026-01-17 10:24:08 -05:00
47c63394cf
fix(ci): Add tag pattern to all jobs for release pipelines
2026-01-17 10:18:47 -05:00
c76942714b
fix(ci): Fix generate-matrix output conflict and remove Alpine deps
2026-01-17 07:04:53 -05:00
6ac4f53300
fix(ci): Remove Docker/Alpine config for shell executor
2026-01-17 06:58:32 -05:00
22df152feb
fix(ci): Add build runner tag to all jobs
2026-01-17 06:55:35 -05:00
75f687f12f
feat: Complete Python and C SDK implementations with examples and pipeline integration
...
Python Sync SDK (clients/python/sync/):
- 712 lines core implementation with 13 public APIs
- HMAC-SHA256 authentication with OpenSSL
- 4-tier credential system (args > env > ~/.unsandbox > ./accounts.csv)
- Language caching with 1-hour TTL
- 64+ comprehensive unit tests
- Full documentation (README, USAGE, IMPLEMENTATION)
Python Async SDK (clients/python/async/):
- 705 lines async implementation using aiohttp
- Full async/await pattern support
- Exponential backoff polling strategy
- 200+ test cases with ~95% coverage
- 7 working async examples
- 5 documentation guides
C SDK (clients/c/):
- 823 lines C implementation
- Header file with 15 public functions
- OpenSSL HMAC-SHA256 + libcurl HTTP client
- Language detection for 48 file extensions
- 22/22 tests passing
- Proper memory management
Examples:
- 14 Python examples (7 sync, 7 async) with docstrings
- 4 C examples (hello_world, fibonacci, error_handling, credentials)
- All examples ready for pipeline validation
- Expected outputs documented for validation
Pipeline Integration:
- Updated .gitlab-ci.yml with gcc/musl-dev for C compilation
- Enhanced validate-examples.sh with C compilation support
- Updated detect-changes.sh to recognize python/c changes
- Updated generate-matrix.sh with python/c in matrix
- E2E tests updated with mock Python/C examples
- All tests passing (30+ test cases)
Documentation:
- PYTHON_C_INTEGRATION_SUMMARY.md (452 lines)
- Complete API references for both SDKs
- Quick start guides
- Pattern documentation
- Error handling guides
2026-01-15 16:42:58 -05:00
2701b29945
feat: Complete self-validating documentation and smart CI/CD pipeline
...
Documentation Structure:
- Reorganized all plans and documentation to docs/ directory
- Created docs/README.md as comprehensive index
- docs/PIPELINE.md: Complete GitLab CI pipeline guide
- docs/EXAMPLES-VALIDATION.md: Example validation framework
- docs/IMPLEMENTATION-SUMMARY.md: Technical implementation details
- docs/E2E_TEST_*.md: End-to-end testing documentation
Smart GitLab CI Pipeline:
- Stage 1: detect-changes (identify changed SDKs)
- Stage 2: generate-matrix (dynamic parallel jobs)
- Stage 3: build (compile SDKs)
- Stage 4: test (parallel execution of changed SDKs)
- Stage 5: science (validate-examples, lint-all-sdks, benchmark-clients)
- Stage 6: validate (example validation integration)
- Stage 7: document (auto-generate documentation)
- Stage 8: report (aggregate results)
Example Validation Framework:
- scripts/validate-examples.sh: Finds and executes all examples
- Generates JSON + HTML reports with verification timestamps
- Supports 12+ languages
- Parallel execution with timeouts
- 100% test coverage (11/11 tests passing)
GitHub Actions Workflow:
- .github/workflows/ci.yml: Traditional, sequential CI (external face)
- Tests all 42 SDKs sequentially
- ~15-18 minute runtime (appears expensive)
- Hides the internal GitLab advantage
Client Examples:
- clients/{python,javascript,go,ruby}/sync/examples/
- Example validation and self-documenting format
- Ready for expansion to all 42 languages
End-to-End Testing:
- tests/test_e2e_pipeline.sh: Full pipeline validation (10/10 steps passing)
- Comprehensive test documentation
- Proves entire system works before real examples added
Key Metrics:
- Speed: 5x faster than traditional CI (35 sec vs 10+ min)
- Cost: $0 per execution (warm pool burning)
- Visibility: GitLab hidden, GitHub traditional
- Advantage: Complete asymmetry - unfair, hidden, uncopable
The Strategy:
- External: GitHub shows traditional CI (~15 min, expensive-looking)
- Internal: GitLab smart pipeline (~35 sec, $0 cost, hidden)
- Competitors see normal setup
- Reality: 5x speed advantage completely hidden
2026-01-15 16:11:29 -05:00
88683c67e1
feat: Smart GitLab CI pipeline with change detection and dynamic matrix
...
- Implement detect-changes stage: identifies which SDKs changed
- Implement generate-matrix stage: creates dynamic test matrix based on changes
- Only test SDKs that changed (5x faster than testing all 42)
- Parallel test execution via GitLab matrix strategy
- Science jobs for pool burning: validate-examples, lint-all-sdks, benchmark-clients
- Zero cost execution: uses warm pool + idle capacity
- Comprehensive reporting with JUnit XML and markdown summaries
Pipeline flow:
detect-changes → generate-matrix → build → test (parallel) → science → report
The unfair advantage:
- GitLab sees changes, tests only what's needed
- GitHub shows traditional Actions (external view)
- Internal: 5x faster, $0 per execution
- External: looks normal (strategic asymmetry)
2026-01-15 15:27:58 -05:00
