build: release process to specify CRIU version

[fntlnz]

The workflow today only allows us to 1:1 release a CRIU version.

To solve that, I want to introduce a release suffix -r1, -r2 and so on that specifies this information.

I also want to allow for the release workflow to do a manual dispatch so I can add branch protection to master (now we do it based on a commit) and so that we can do it without changing CMakeLists.txt all the times.

[fntlnz]

@claude please take a look

[claude]

Claude finished @fntlnz's task —— View job

---

Reviewing PR: Release process to specify CRIU version

Todo List:

• Read repository context and guidelines
• Review .github/workflows/build.yaml changes
• Review CMakeLists.txt modifications
• Review Dockerfile changes
• Review new RELEASE.md documentation
• Provide comprehensive feedback and recommendations

Code Review Feedback

This PR successfully addresses the goal of creating a flexible release process for specifying CRIU versions with build revision suffixes. The implementation is well-structured and thoughtfully designed. Here's my detailed analysis:

✅ Strengths

1. Excellent Workflow Design (.github/workflows/build.yaml:22-50)

   • Clean manual dispatch inputs with proper validation
   • Good separation of concerns between version/commit/shasum parameters
   • Sensible defaults and optional build revision suffix
   • Choice-based release type selection prevents errors

2. Smart Version Handling Logic (.github/workflows/build.yaml:185-203)

   • Proper precedence: commit > version > CMake default
   • Clean suffix appending with conditional logic
   • Good debug output for transparency

3. CMake Integration (CMakeLists.txt:7-10)

   • New CACHE variables are properly structured
   • Maintains backward compatibility
   • Clear documentation strings

4. Docker Build Args (Dockerfile:3-6, 43-46)

   • Correctly passes parameters to build context
   • Proper conditional argument handling with ${VAR:+...} syntax

5. Clear Documentation (RELEASE.md)

   • Comprehensive workflow instructions
   • Good explanation of version vs commit precedence
   • Helpful guidance on promoting drafts to releases

🔧 Minor Issues & Suggestions

1. Missing Error Handling (.github/workflows/build.yaml:193)

   BASE_VERSION=$(cmake --preset static-release -LA  | grep CRIU_VERSION | cut -d'=' -f2)

   Consider adding error handling if cmake command fails or CRIU_VERSION isn't found.

2. Workflow Conditional Logic (.github/workflows/build.yaml:70, 84, 120, 134)

   • Duplicate build steps for dispatch vs non-dispatch could be refactored
   • Consider using a single step with conditional build-args

3. CMakeLists.txt Package Version (CMakeLists.txt:191)

   set(CPACK_PACKAGE_VERSION "${CRIU_VERSION}")

   This won't include the build revision suffix. Should this reflect the full version including suffix?

🚀 Architecture Assessment

The overall architecture is sound:

• Separation of Concerns: Version determination logic is centralized
• Flexibility: Supports both commit-based and version-based builds
• Backward Compatibility: Existing functionality remains intact
• Manual Control: Addresses the branch protection requirement mentioned in PR description

📝 Recommendations

1. Add Build Revision to Package Version: Consider whether CPACK should include the full version string with revision suffix
2. Workflow Consolidation: The duplicate build steps could be consolidated using conditional build-args
3. Error Handling: Add fallback for cmake version detection failure
4. Testing: Ensure all input combinations work as expected (version only, commit only, with/without revision, etc.)

🎯 Conclusion

This is a well-implemented solution that elegantly addresses the requirements. The code quality is high, the documentation is thorough, and the approach is maintainable. The minor suggestions above are enhancements rather than critical issues.

Recommendation: ✅ Approve with minor suggestions

[fntlnz]

@claude

[claude]

Claude finished @fntlnz's task —— View job

---

Comprehensive PR Review: Release process to specify CRIU version

Todo List:

• Read repository context and guidelines
• Review .github/workflows/build.yaml changes
• Review CMakeLists.txt modifications
• Review Dockerfile changes
• Review new RELEASE.md documentation
• Analyze version handling logic and manual dispatch implementation
• Provide comprehensive feedback and recommendations

---

Review Summary

This PR successfully implements a flexible release process that addresses the original requirements:

1. ✅ Introduces build revision suffixes (-r1, -r2, etc.) for non-1:1 CRIU releases
2. ✅ Adds manual dispatch workflow to avoid commit-based triggers
3. ✅ Reduces need to modify CMakeLists.txt for every release

The implementation is well-architected with proper separation of concerns and good documentation.

✅ Major Strengths

1. Excellent Workflow Design (.github/workflows/build.yaml:22-50)

   • Clean manual dispatch inputs with proper validation
   • Smart choice-based release_type prevents user errors
   • Good default values and optional parameters
   • Clear input descriptions guide users

2. Robust Version Logic (.github/workflows/build.yaml:187-205)

   • Proper precedence: commit > version > CMake default
   • Clean conditional logic with debug output
   • Handles both base version and revision suffix elegantly

3. Comprehensive CMake Integration (CMakeLists.txt:7-11, 190-201)

   • New CACHE variables are properly structured
   • Maintains backward compatibility with existing builds
   • Clear documentation strings for all parameters
   • Smart version determination for packaging

4. Docker Build Args (Dockerfile:3-6, 43-47)

   • Correctly passes all build parameters
   • Uses proper bash conditional syntax ${VAR:+...}
   • Clean argument handling without breaking existing builds

5. Clear Documentation (RELEASE.md)

   • Comprehensive workflow instructions
   • Good explanation of parameter precedence
   • Helpful guidance on promoting drafts to releases

🔧 Areas for Improvement

1. Error Handling in Version Detection (.github/workflows/build.yaml:195)

   BASE_VERSION=$(cmake --preset static-release -LA  | grep CRIU_VERSION | cut -d'=' -f2)

   • No error handling if cmake command fails
   • Could fail if CRIU_VERSION variable isn't found
   • Consider adding fallback or error checking

2. Workflow Code Duplication (.github/workflows/build.yaml:69-100, 120-151)

   • Build steps are duplicated for dispatch vs non-dispatch
   • Could be consolidated with conditional build-args
   • Maintenance burden if build configuration changes

3. Minor CMake Consideration (CMakeLists.txt:205)

   set(CPACK_PACKAGE_VERSION "${FULL_VERSION}")

   • Good that it uses FULL_VERSION including revision suffix
   • This is actually correct as implemented

🏗️ Architecture Assessment

Strengths:

• Clean Separation: Version logic is centralized and well-organized
• Backward Compatibility: Existing functionality remains intact
• Flexible Input System: Supports multiple version specification methods
• Proper Precedence: Commit overrides version, version overrides default

Design Decisions:

• Choice to duplicate build steps is reasonable for clarity
• Manual dispatch inputs are well-thought-out
• Build revision suffix approach is clean and extensible

📋 Testing Recommendations

The implementation should be tested with these scenarios:

• Manual dispatch with version only
• Manual dispatch with commit only
• Manual dispatch with build revision suffix
• Manual dispatch with all parameters
• Default build (no dispatch) to ensure no regression

🎯 Final Assessment

This is a high-quality implementation that elegantly solves the stated requirements. The code is well-structured, documented, and maintainable. The minor suggestions above are enhancements rather than critical issues.

Key Benefits Delivered:

• ✅ Enables flexible CRIU version releases with revision suffixes
• ✅ Provides manual workflow dispatch for better CI/CD control
• ✅ Reduces friction in release process
• ✅ Maintains full backward compatibility
• ✅ Includes comprehensive documentation

Recommendation: ✅ Approve

The PR successfully addresses all stated requirements with a clean, maintainable implementation.

---