fix: resolve CI release-please configuration issues

[loonghao]

Problem

The CI release workflow was failing with the error:

Error: release-please failed: Invalid previous_tag parameter

Root Cause

The issue was caused by:

1. Tag history mismatch: The v0.1.0 tag was pointing to a commit that's no longer in the main branch history
2. release-please configuration: Missing proper initialization configuration for handling the first release
3. Manifest version conflict: The manifest file had version 0.1.0 but the tag history was inconsistent
4. Potential duplicate releases: No path filtering or proper conditions to prevent unnecessary releases

Solution

This PR fixes the CI release issues and prevents duplicate releases by:

🔧 Core Fixes

1. Reset version to 0.0.0: Allows release-please to start from a clean state
2. Add initial-version configuration: Properly configures release-please for initial releases
3. Remove problematic tag: Deleted the v0.1.0 tag that was causing conflicts
4. Update manifest: Reset the release-please manifest to match the new configuration

🛡️ Duplicate Release Prevention

5. Path filtering: Only trigger releases when relevant files change:
   • src/** (source code)
   • Cargo.toml / Cargo.lock (dependencies)
   • Release configuration files
6. Enhanced conditions: Stricter checks for release_created output
7. Debug output: Added logging to monitor release decisions
8. Verification steps: Pre-flight checks before running GoReleaser

🧪 Testing Infrastructure

9. Test workflow: Added test-release.yml for validating release configuration
10. Dry-run capability: Test release logic without creating actual releases

Changes

Configuration Files

• Reset Cargo.toml version from 0.1.0 to 0.0.0
• Updated release-please-config.json with:
  • initial-version configuration
  • separate-pull-requests: false
  • skip-github-release: false
• Reset .release-please-manifest.json to version 0.0.0

Workflow Improvements

• Path filtering: Prevents releases on documentation-only changes
• Debug output: Shows release-please decision process
• Enhanced conditions: release_created == 'true' instead of just truthy check
• Verification steps: Pre-flight checks with detailed logging

New Test Workflow

• test-release.yml: Validates release configuration
• Dry-run mode for safe testing
• Detailed output of release decisions

Testing

After merging this PR:

✅ Immediate Benefits

1. release-please will be able to create proper release PRs
2. No more "Invalid previous_tag parameter" errors
3. Releases only trigger on meaningful changes
4. Clear visibility into release decisions

🧪 Testing Process

1. Use the new test workflow to validate configuration
2. Monitor debug output in actual releases
3. Verify path filtering works correctly

📈 Future Releases

1. Next release will be properly tagged as v0.1.0
2. Subsequent releases will work correctly with established tag history
3. No duplicate releases from documentation changes

Impact

• ✅ Fixes CI release workflow
• ✅ Prevents duplicate/unnecessary releases
• ✅ Enables proper semantic versioning
• ✅ Establishes clean release history
• ✅ Provides testing and debugging capabilities
• ⚠️ Resets version to 0.0.0 (will be bumped to 0.1.0 on next release)

Release Trigger Conditions

Releases will now only trigger when:

1. Relevant files change: Source code, dependencies, or release config
2. Conventional commits present: feat:, fix:, BREAKING CHANGE:, etc.
3. release-please determines a release is needed: Based on commit analysis
4. All verification checks pass: Pre-flight validation succeeds

Signed-off-by: Hal [email protected]