Revert "Add GitHub release workflow for multi-platform builds"

[lookbusy1344]

Reverts #35

[claude]

PR Review: Revert Release Workflow

Summary

This PR reverts the GitHub Actions release workflow added in #35. While reverting is sometimes necessary, I've analyzed the original workflow to identify potential issues that may have prompted this revert.

Analysis of the Reverted Workflow

Potential Issues Identified

1. Cross-compilation Concerns

• Windows ARM64 build on Windows AMD64 runner: The workflow attempts to build aarch64-pc-windows-msvc on a windows-latest runner, which is typically AMD64. Cross-compilation for Windows ARM64 may require additional setup or may not work without proper toolchain configuration.
• Recommendation: Consider using appropriate runners or document the cross-compilation requirements explicitly.

2. Missing Dependency Installation

• The workflow doesn't install any system dependencies that might be required for cross-compilation (e.g., cross-compilation toolchains, linkers).
• For Linux cross-compilation, packages like gcc-aarch64-linux-gnu might be needed.

3. Build Verification

• No testing or verification steps after building. The binaries are created and uploaded without validation.
• Recommendation: Add basic smoke tests (e.g., ./binary --version or --help) to ensure binaries are functional.

4. Artifact Naming

• Using the same artifact name as the binary filename could cause confusion. Artifacts are downloaded into folders with the artifact name.
• The workflow tries to access artifacts/*/* which assumes a specific directory structure.

5. Tag Format

• The workflow triggers on v* tags but doesn't validate the tag format or extract version information.
• Current Cargo.toml shows version "1.5.0", but there are no existing tags in the repository yet.

Security Considerations

• GITHUB_TOKEN permissions: The workflow uses permissions: contents: write at the workflow level, which is appropriate for creating releases.
• No artifact verification: Binaries are not signed or checksummed, making it harder for users to verify authenticity.

Performance Considerations

• Sequential artifact downloads: The release job downloads all artifacts sequentially, which is fine for 4 binaries but could be optimized.
• Build parallelization: The matrix strategy correctly parallelizes builds across different runners, which is good.

Best Practices

✅ Good:

• Uses actions/checkout@v4 (latest major version)
• Sets if-no-files-found: error for artifact uploads
• Enables generate_release_notes: true
• Appropriate permissions scope

⚠️ Could be improved:

• No caching of Rust dependencies (consider adding Swatinem/rust-cache@v2)
• No checksum generation for release binaries
• Missing macOS x86_64 target (Intel Macs)
• No smoke tests for built binaries

Recommendations for Future Release Workflow

If you plan to re-implement this workflow, consider:

1. Add caching to speed up builds:

   - uses: Swatinem/rust-cache@v2
     with:
       key: ${{ matrix.target }}

2. Add smoke tests before uploading:

   - name: Test binary
     run: ./${{ matrix.name }} --version

3. Generate checksums:

   - name: Generate checksum
     run: sha256sum ${{ matrix.name }} > ${{ matrix.name }}.sha256

4. Consider using cargo-zigbuild or cross for more reliable cross-compilation.

5. Add macOS Intel target: x86_64-apple-darwin

6. Separate ARM64 Windows builds into a dedicated job with appropriate documentation about cross-compilation limitations.

Conclusion

The revert is a clean removal of the workflow file with no code quality issues in the revert itself. If the original workflow failed during execution, the issues above are likely candidates for why. The workflow would benefit from testing in a fork first or using a draft release for initial validation.

Review Status: ✅ Approved for merge (revert is clean)
Future Workflow: Would benefit from addressing the issues above

---

Review performed by Claude Code analyzing HashRust conventions