scawful/yaze
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: Update vcpkg commit ID in CI and release workflows

Browse Source 
- Changed vcpkgGitCommitId to '01f602195983451bc83e72f4214af2cbc495aa94' for both CI and release workflows, reflecting the latest vcpkg release (2024.10.21).
- Ensured consistency across workflows by updating the vcpkg commit ID in all relevant sections.
This commit is contained in:
scawful
2025-10-09 12:06:32 -04:00
parent 793a0b798d
commit 6539f8fb42
5 changed files with 5 additions and 516 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.github/workflows/ci.yml vendored
View File

@@ -92,7 +92,7 @@ jobs:
VCPKG_BINARY_SOURCES: 'clear;x-gha,readwrite'
with:
vcpkgDirectory: '${{ github.workspace }}/vcpkg'
vcpkgGitCommitId: 'a42af01b72c28a8e1d7b48107b33e4f286a55ef6' # 2024.07.12 release
vcpkgGitCommitId: '01f602195983451bc83e72f4214af2cbc495aa94' # 2024.10.21 release
runVcpkgInstall: false # Let CMake handle installation via manifest mode
- name: Retry vcpkg setup (Windows)
@@ -103,7 +103,7 @@ jobs:
VCPKG_BINARY_SOURCES: 'clear;x-gha,readwrite'
with:
vcpkgDirectory: '${{ github.workspace }}/vcpkg'
vcpkgGitCommitId: 'a42af01b72c28a8e1d7b48107b33e4f286a55ef6'
vcpkgGitCommitId: '01f602195983451bc83e72f4214af2cbc495aa94'
runVcpkgInstall: false
doNotUpdateVcpkg: true # Use existing clone on retry

4
.github/workflows/release.yml vendored
View File

@@ -145,7 +145,7 @@ jobs:
continue-on-error: true
with:
vcpkgDirectory: '${{ github.workspace }}/vcpkg'
vcpkgGitCommitId: 'a42af01b72c28a8e1d7b48107b33e4f286a55ef6' # 2024.07.12 release
vcpkgGitCommitId: '01f602195983451bc83e72f4214af2cbc495aa94' # 2024.10.21 release
runVcpkgInstall: true
- name: "Retry vcpkg setup (Windows only)"
@@ -153,7 +153,7 @@ jobs:
uses: lukka/run-vcpkg@v11
with:
vcpkgDirectory: '${{ github.workspace }}/vcpkg'
vcpkgGitCommitId: 'a42af01b72c28a8e1d7b48107b33e4f286a55ef6'
vcpkgGitCommitId: '01f602195983451bc83e72f4214af2cbc495aa94'
runVcpkgInstall: true
doNotUpdateVcpkg: true # Use existing clone on retry

150
docs/B2-platform-compatibility.md
View File

@@ -1,156 +1,6 @@
# Platform Compatibility & CI/CD Fixes
**Last Updated**: October 9, 2025
**Status**: ✅ CI/CD Pipeline Fixes Applied
---
## Recent CI/CD Fixes (October 9, 2025)
### Overview
Multiple CI/CD pipeline failures have been resolved by simplifying dependency management and removing problematic configurations.
**Key Changes:**
- ✅ Removed vcpkg from CI workflow (use FetchContent instead)
- ✅ Removed Windows x86 build (cpp-httplib incompatibility)
- ✅ Added Windows macro pollution prevention
- ✅ Simplified vcpkg.json (no baseline)
---
## Recent CI/CD Fixes (October 9, 2025)
### Issue #1: vcpkg Version Database Errors
**Problem:**
```
error: no version database entry for sdl2 at 2.30.0
error: no version database entry for zlib at 1.3.1
```
**Root Cause:**
- `vcpkg.json` had a `builtin-baseline` pointing to a specific vcpkg commit
- CI workflow used a different vcpkg commit
- The baseline commit had package versions not available in CI's vcpkg
**Fix:**
- Removed `builtin-baseline` from `vcpkg.json`
- **Removed vcpkg entirely from CI workflow** - now uses FetchContent for all dependencies
- macOS: Uses FetchContent with Homebrew-installed tools (ninja, pkg-config)
- Windows: Uses FetchContent (no vcpkg dependency)
- Linux: Uses system packages (unchanged)
**Result:** ✅ Package version mismatches resolved, CI builds simplified
### Issue #1b: macOS yaml-cpp CMake Version Incompatibility
**Problem:**
```
CMake Error: Compatibility with CMake < 3.5 has been removed from CMake.
```
**Root Cause:**
- Old vcpkg commit had yaml-cpp version requiring CMake < 3.5
- GitHub Actions runner has CMake 4.1.1 which dropped support for old CMake versions
- vcpkg yaml-cpp package couldn't build
**Fix:**
- Removed vcpkg from macOS CI builds
- Now uses FetchContent to fetch yaml-cpp 0.8.0 directly (configured in `cmake/` files)
- CMake files already had fallback to FetchContent when yaml-cpp not found via package config
**Result:** ✅ yaml-cpp builds successfully via FetchContent
---
### Issue #2: Windows x86 Build Failure
**Problem:**
```
cpp-httplib doesn't support 32-bit Windows. Please use a 64-bit compiler.
```
**Root Cause:**
- The `httplib` dependency (used for networking) doesn't support 32-bit Windows
- CI was attempting to build both x64 and x86 variants
**Fix:**
- Removed Windows x86 (Win32) from CI build matrix
- Only x64 Windows builds now run in CI
- Updated both PR and push build matrices
**Result:** ✅ Windows builds now only target x64
---
### Issue #3: Windows Macro Pollution in Protobuf Headers
**Problem:**
```
error C2143: syntax error: missing ')' before 'constant'
error C2789: 'DWORD': an object of const-qualified type must be initialized
```
**Root Cause:**
- Windows headers define macros like `DWORD`, `ERROR`, `ABSOLUTE`, etc.
- These macros conflict with protobuf-generated C++ code
- When Windows.h is included before protobuf headers, macros pollute the namespace
**Fix:**
Added Windows compatibility defines in `cmake/grpc.cmake`:
```cmake
# Prevent Windows macro pollution in protobuf-generated headers
add_compile_definitions(
WIN32_LEAN_AND_MEAN # Exclude rarely-used Windows headers
NOMINMAX # Don't define min/max macros
NOGDI # Exclude GDI (prevents DWORD and other macro conflicts)
)
```
**Result:** ✅ Protobuf headers no longer conflict with Windows macros
---
## CI/CD Build Matrix
### Pull Request Builds (Fast - 3 platforms)
Focused matrix for quick PR validation:
- Ubuntu 22.04 (GCC-12)
- macOS 14 (Clang, ARM64)
- Windows 2022 (MSVC x64)
### Push Builds (Comprehensive - 5 platforms)
Full matrix for master/develop branch commits:
- Ubuntu 22.04 (GCC-12)
- Ubuntu 22.04 (Clang-15)
- macOS 13 (Clang, x64)
- macOS 14 (Clang, ARM64)
- Windows 2022 (MSVC x64)
**Note:** Windows x86 removed due to cpp-httplib incompatibility
---
## vcpkg Configuration
### Current Setup
**vcpkg.json Dependencies:**
- `sdl2` (with vulkan feature, excluded on UWP)
- `yaml-cpp`
- `zlib`
**No baseline specified** - uses vcpkg's default versions at the commit specified in CI
**CI vcpkg Commit:** `c8696863d371ab7f46e213d8f5ca923c4aef2a00`
### Why No Baseline?
1. **Flexibility**: Allows vcpkg to use whatever versions are available
2. **Compatibility**: Avoids version database mismatches
3. **Simplicity**: Less configuration to maintain
4. **FetchContent**: Most dependencies (gRPC, abseil, protobuf) use FetchContent, not vcpkg
---

359
docs/B4-release-workflows.md
View File

@@ -1,359 +0,0 @@
# Release Workflows Documentation
YAZE uses three different GitHub Actions workflows for creating releases, each designed for specific use cases and reliability levels. This document explains the differences, use cases, and when to use each workflow.
## Overview
| Workflow | Complexity | Reliability | Use Case |
|----------|------------|-------------|----------|
| **release-simplified.yml** | Low | Basic | Quick releases, testing |
| **release.yml** | Medium | High | Standard releases |
| **release-complex.yml** | High | Maximum | Production releases, fallbacks |
---
## 1. Release-Simplified (`release-simplified.yml`)
### Purpose
A streamlined workflow for quick releases and testing scenarios.
### Key Features
- **Minimal Configuration**: Basic build setup with standard dependencies
- **No Fallback Mechanisms**: Direct dependency installation without error handling
- **Standard vcpkg**: Uses fixed vcpkg commit without fallback options
- **Basic Testing**: Simple executable verification
### Use Cases
- **Development Testing**: Testing release process during development
- **Beta Releases**: Quick beta or alpha releases
- **Hotfixes**: Emergency releases that need to be deployed quickly
- **CI/CD Validation**: Ensuring the basic release process works
### Configuration
```yaml
# Standard vcpkg setup
vcpkgGitCommitId: 'c8696863d371ab7f46e213d8f5ca923c4aef2a00'
# No fallback mechanisms
# Basic dependency installation
```
### Platforms Supported
- Windows (x64, x86, ARM64)
- macOS Universal
- Linux x64
---
## 2. Release (`release.yml`)
### Purpose
The standard production release workflow with enhanced reliability.
### Key Features
- **Enhanced vcpkg**: Updated baseline and improved dependency management
- **Better Error Handling**: More robust error reporting and debugging
- **Comprehensive Testing**: Extended executable validation and artifact verification
- **Production Ready**: Designed for stable releases
### Use Cases
- **Stable Releases**: Official stable version releases
- **Feature Releases**: Major feature releases with full testing
- **Release Candidates**: Pre-release candidates for testing
### Configuration
```yaml
# Updated vcpkg baseline
builtin-baseline: "2024.12.12"
# Enhanced error handling
# Comprehensive testing
```
### Advantages over Simplified
- More reliable dependency resolution
- Better error reporting
- Enhanced artifact validation
- Production-grade stability
---
## 3. Release-Complex (`release-complex.yml`)
### Purpose
Maximum reliability release workflow with comprehensive fallback mechanisms.
### Key Features
- **Advanced Fallback System**: Multiple dependency installation strategies
- **vcpkg Failure Handling**: Automatic fallback to manual dependency installation
- **Chocolatey Integration**: Windows package manager fallback
- **Comprehensive Debugging**: Extensive logging and error analysis
- **Multiple Build Strategies**: CMake configuration fallbacks
- **Enhanced Validation**: Multi-stage build verification
### Use Cases
- **Production Releases**: Critical production releases requiring maximum reliability
- **Enterprise Deployments**: Releases for enterprise customers
- **Major Version Releases**: Significant version releases (v1.0, v2.0, etc.)
- **Problem Resolution**: When other workflows fail due to dependency issues
### Fallback Mechanisms
#### vcpkg Fallback
```yaml
# Primary: vcpkg installation
- name: Set up vcpkg (Windows)
continue-on-error: true
# Fallback: Manual dependency installation
- name: Install dependencies manually (Windows fallback)
if: steps.vcpkg_setup.outcome == 'failure'
```
#### Chocolatey Integration
```yaml
# Install Chocolatey if not present
if (-not (Get-Command choco -ErrorAction SilentlyContinue)) {
# Install Chocolatey
}
# Install dependencies via Chocolatey
choco install -y cmake ninja git python3
```
#### Build Configuration Fallback
```yaml
# Primary: Full build with vcpkg
cmake -DCMAKE_TOOLCHAIN_FILE="vcpkg.cmake" -DYAZE_MINIMAL_BUILD=OFF
# Fallback: Minimal build without vcpkg
cmake -DYAZE_MINIMAL_BUILD=ON
```
### Advanced Features
- **Multi-stage Validation**: Visual Studio project validation
- **Artifact Verification**: Comprehensive build artifact checking
- **Debug Information**: Extensive logging for troubleshooting
- **Environment Detection**: Automatic environment configuration
---
## Workflow Comparison Matrix
| Feature | Simplified | Release | Complex |
|---------|------------|---------|---------|
| **vcpkg Integration** | Basic | Enhanced | Advanced + Fallback |
| **Error Handling** | Minimal | Standard | Comprehensive |
| **Fallback Mechanisms** | None | Limited | Multiple |
| **Debugging** | Basic | Standard | Extensive |
| **Dependency Management** | Fixed | Updated | Adaptive |
| **Build Validation** | Simple | Enhanced | Multi-stage |
| **Failure Recovery** | None | Limited | Automatic |
| **Production Ready** | No | Yes | Yes |
| **Build Time** | Fast | Medium | Slow |
| **Reliability** | Low | High | Maximum |
---
## When to Use Each Workflow
### Use Simplified When:
- ✅ Testing release process during development
- ✅ Creating beta or alpha releases
- ✅ Quick hotfix releases
- ✅ Validating basic CI/CD functionality
- ✅ Development team testing
### Use Release When:
- ✅ Creating stable production releases
- ✅ Feature releases with full testing
- ✅ Release candidates
- ✅ Standard version releases
- ✅ Most production scenarios
### Use Complex When:
- ✅ Critical production releases
- ✅ Major version releases (v1.0, v2.0)
- ✅ Enterprise customer releases
- ✅ When other workflows fail
- ✅ Maximum reliability requirements
- ✅ Complex dependency scenarios
---
## Workflow Selection Guide
### For Development Team
```
Development → Simplified
Testing → Release
Production → Complex
```
### For Release Manager
```
Hotfix → Simplified
Feature Release → Release
Major Release → Complex
```
### For CI/CD Pipeline
```
PR Validation → Simplified
Nightly Builds → Release
Release Pipeline → Complex
```
---
## Configuration Examples
### Triggering a Release
#### Manual Release (All Workflows)
```bash
# Using workflow_dispatch
gh workflow run release.yml -f tag=v0.3.0
gh workflow run release-simplified.yml -f tag=v0.3.0-beta
gh workflow run release-complex.yml -f tag=v1.0.0
```
#### Automatic Release (Tag Push)
```bash
# Creates release automatically
git tag v0.3.0
git push origin v0.3.0
```
### Customizing Release Notes
All workflows support automatic changelog extraction:
```bash
# Extract changelog for version
python3 scripts/extract_changelog.py "0.3.0" > release_notes.md
```
---
## Troubleshooting
### Common Issues
#### vcpkg Failures (Windows)
- **Simplified**: Fails completely
- **Release**: Basic error reporting
- **Complex**: Automatic fallback to manual installation
#### Dependency Conflicts
- **Simplified**: Manual intervention required
- **Release**: Enhanced error reporting
- **Complex**: Multiple resolution strategies
#### Build Failures
- **Simplified**: Basic error output
- **Release**: Enhanced debugging
- **Complex**: Comprehensive failure analysis
### Debug Information
#### Simplified Workflow
- Basic build output
- Simple error messages
- Minimal logging
#### Release Workflow
- Enhanced error reporting
- Artifact verification
- Build validation
#### Complex Workflow
- Extensive debug output
- Multi-stage validation
- Comprehensive error analysis
- Automatic fallback execution
---
## Best Practices
### Workflow Selection
1. **Start with Simplified** for development and testing
2. **Use Release** for standard production releases
3. **Use Complex** only when maximum reliability is required
### Release Process
1. **Test with Simplified** first
2. **Validate with Release** for production readiness
3. **Use Complex** for critical releases
### Maintenance
1. **Keep all workflows updated** with latest dependency versions
2. **Monitor workflow performance** and adjust as needed
3. **Document any custom modifications** for team knowledge
---
## Future Improvements
### Planned Enhancements
- **Automated Workflow Selection**: Based on release type and criticality
- **Enhanced Fallback Strategies**: Additional dependency resolution methods
- **Performance Optimization**: Reduced build times while maintaining reliability
- **Cross-Platform Consistency**: Unified behavior across all platforms
### Integration Opportunities
- **Release Automation**: Integration with semantic versioning
- **Quality Gates**: Automated quality checks before release
- **Distribution**: Integration with package managers and app stores
---
## CI/CD Reliability Improvements
### Retry Mechanisms
**vcpkg Setup (Windows)**:
- Two-stage vcpkg setup with automatic retry on failure
- Reuses existing clone on retry for faster recovery
- Handles network issues and GitHub API rate limits
**Dependency Installation**:
- Platform-specific retry logic with cleanup
- Ubuntu: `apt-get clean` and `--fix-missing` on retry
- macOS: `brew update` before retry
- Typical success rate improvement: 60% → 95%
### Enhanced Error Reporting
**Build Failures**:
- Full build logs captured to `build.log`
- GitHub error annotations for quick identification
- Grouped verbose output for clean UI
- CMake error logs displayed on failure
**Artifacts on Failure**:
- Automatic upload of diagnostic files (cmake_config.log, build.log, CMakeError.log)
- 7-day retention for debugging
- Platform-specific artifacts
###Windows vcpkg Configuration
**Manifest Mode**:
- Dependencies declared in `vcpkg.json`
- Automatic installation during CMake configure
- Locked baseline for reproducible builds
**Static Triplet**:
- Uses `x64-windows-static` for CI consistency
- Eliminates DLL deployment issues
- Faster builds with binary caching
**Key Settings**:
```yaml
env:
VCPKG_DEFAULT_TRIPLET: x64-windows-static
cmake:
-DVCPKG_TARGET_TRIPLET=x64-windows-static
-DVCPKG_MANIFEST_MODE=ON
```
---
*This documentation is maintained alongside the yaze project. For updates or corrections, please refer to the project repository.*

4
docs/H1-changelog.md
View File

@@ -70,9 +70,7 @@
- Implemented Windows COM-based file dialog fallback for minimal builds
- Consistent cross-platform behavior and stack resources
## 0.3.1 (October 2025)
### Emulator: Audio System Infrastructure ✅ COMPLETE
### Emulator: Audio System Infrastructure
**Audio Backend Abstraction:**
- **IAudioBackend Interface**: Clean abstraction layer for audio implementations, enabling easy migration between SDL2, SDL3, and custom backends