fix: release pipeline

[lpahlavi]

Currently, release-plz runs into issues when trying to determine the next version of the sol_rpc_canister crate. This is because the sol_rpc_canister crate is a binary crate and hence not published on crates.io. However, since a release tag exists for the crate, release-plz tries to download the latest release from crates.io and fails. See this failed release pipeline run for example.

I've opened a PR to fix this issue in the upstream release-plz repository, and updated the release pipeline here to build the release-plz GitHub action from source to include those changes. This is a temporary solution until the changes are merged in the upstream repository. The release pipeline runs again successfully when using the patched release-plz GitHub action (see this run).

[lpahlavi]

@gregorydemay See the updated PR description. I've opened an issue and PR in the upstream release-plz repository and this PR now just uses the patched GitHub action in the meantime until those changes are merged upstream.

Note that after running the release pipeline, the generated PR didn't update the sol_rpc_canister version. I think that's just because there are no commits directly changing the Rust code in there. WDYT?

[gregorydemay]

Thanks for the fix!

[gregorydemay]

do we really need nightly?

[lpahlavi]

Actually it was a huge pain to get release-plz to compile from source (see the commits in this branch 😅) due to their use of some unstable features (I believe if let chains in if statements) and conflicts with the sol-rpc-canister repo Rust version. I guess this should hopefully be just a temporary fix so I thought it's good enough, but we can also experiment to find was versions of Rust work. WDYT?

[gregorydemay]

If it's just to compile release-plz, then I'm totally fine with it, but I'm more worried that nightly could be use to compile the sol-rpc-canister and this would be problematic (for build reproducibility)

[lpahlavi]

I looked into it a bit more and stumbled onto this tracking issue for the problematic unstable feature. Turns out it's enough to just use Rust 1.88.0 to compile the release-plz GitHub action, since the feature became stable then. I just changed the cargo install to use v1.88.0 instead of nightly and it seems to work fine.

[gregorydemay]

@lpahlavi

Note that after running the release pipeline, the generated PR didn't update the sol_rpc_canister version. I think that's just because there are no commits directly changing the Rust code in there. WDYT?

There is one commit that should be picked up if the changelog was automatically generated

git log --format='%C(auto) %h %s' sol_rpc_canister-v1.1.0..HEAD -- canister
 c3d5468 chore: upgrade SOL RPC canister to v1.1.0 (#206)

But that's I think not too tragic and could be manually adapted in the generated PR?

[lpahlavi]

There is one commit that should be picked up if the changelog was automatically generated

git log --format='%C(auto) %h %s' sol_rpc_canister-v1.1.0..HEAD -- canister
 c3d5468 chore: upgrade SOL RPC canister to v1.1.0 (#206)

But that's I think not too tragic and could be manually adapted in the generated PR?

@gregorydemay I guess actually release-plz is smart enough to ignore this commit since it's just updating the crate version. It's not too much of a hassle, but I mostly wanted to make sure I didn't somehow break something in my upstream PR leading to an incomplete changelog / incorrect version determination.