Automate Binary Releases for Noname

[ronantakizawa]

Automating Binary Releases for Noname by getting the latest version tag of Noname from CHANGELOG.md and building the binary release. Resolves issue #81

[katat]

Not quite sure of how this is going to work. Maybe a outline of the workflow is helpful :)

[ronantakizawa]

@katat

Key points

• The workflow only proceeds with the release process if CHANGELOG.md has been updated.
• The versioning is based on incrementing the patch number of the latest tag.
• The binary is built and uploaded only if a new release is necessary.

---

• Trigger: The workflow is triggered by a push to the main branch.

• Steps:

  • Checkout Code:

    • Uses the actions/checkout@v2 to check out the latest code from the main branch.

  • Set Up Rust:

    • Uses the dtolnay/rust-toolchain@stable to set up the Rust environment with the stable toolchain.

  • Check for Changelog Changes:

    • Compares the CHANGELOG.md file between the latest tagged commit and the current commit.
    • If changes are found in CHANGELOG.md, it sets an output needs_release to true.

  • Generate New Version Tag:

    • If needs_release is true, it calculates the next patch version number based on the latest tag.
    • Sets the new version tag as an output.

  • Build the Project:

    • If needs_release is true, it runs cargo build --release to compile the Rust project in release mode.

  • Install GitHub CLI:

    • Installs the GitHub CLI (gh) if a release is needed.

  • Authenticate GitHub CLI:

    • Authenticates the GitHub CLI using a GitHub token from the repository's secrets.

  • Create Release:

    • Uses the GitHub CLI to create a new release with the generated version tag if a release is needed.

  • Upload Assets:

    • Uploads the built binary (noname) as an asset to the GitHub release.

[katat]

Ok, cool. I got a better idea of this works atm.
I think we need to agree on the rule of triggering the release build.

From what @ronantakizawa described above, the rule seems to rely on

• whether the changelog is updated
• simply pick the latest git tag version to build

The potential problem of this approach is it might not be able to correctly pick up the right version corresponding to the changelog. For example,

• When there are multiple versions, but we only documented one of them to release in changelog, which is not necessary the latest version.
• Sometimes, there is a need to simply update some wordings in the changelog, but not necessary meant to build a release for each doc update.

Given the changelog format pattern as the following:

# Changelog

## [Unrelease]
...

## [0.7.0] - yyyy-mm-dd
...

## [0.6.0] - yyyy-mm-dd
....

Maybe the rule can be:

1. always parse for the latest version from the pattern [major.minor.fix] in the changelog
2. compare it with the latest built version, and only build it if the newly parsed version not yet exists in the releases repository.

This way can ensure it build and release the version corresponding to the update to changelog.
cc @mimoo