ci: create release workflow that uses cargo release

[galargh]

This adds release workflow that can be triggered manually which performs the release using cargo release. It requires CARGO_REGISTRY_TOKEN to be set in the repository secrets. The token has to be for one of the users that belong to the proofs-crate-owners team or filecoin-crate-owner.

[Copilot]

Pull Request Overview

This PR adds automated release functionality to the repository by introducing a GitHub Actions workflow that uses cargo release for publishing releases. The changes also update several dependency versions in the Cargo.toml file.

• Creates a manual GitHub Actions workflow for automated releases with configurable release levels (patch, minor, major)
• Updates dependency versions for filecoin-proofs-v1, fr32, and storage-proofs-core packages

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
.github/workflows/release.yml	Adds new release workflow with manual trigger and cargo release automation
Cargo.toml	Updates dependency versions to newer major/minor releases

[Copilot]

There is an extra closing angle bracket '>' at the end of the email address. It should be '${GITHUB_TRIGGERING_ACTOR}@users.noreply.github.com' without the trailing '>'.

Suggested change

	git config --global user.email "${GITHUB_TRIGGERING_ACTOR}@users.noreply.github.com>"
	git config --global user.email "${GITHUB_TRIGGERING_ACTOR}@users.noreply.github.com"

[Copilot]

[nitpick] The cargo-release version is pinned to a specific version (0.25.17). Consider using a more recent version or document why this specific version is required, as newer versions may contain bug fixes and improvements.

Suggested change

	run: cargo install --version 0.25.17 cargo-release
	run: cargo install cargo-release

[Copilot]

Installing packages with sudo without specifying versions could introduce security risks. Consider pinning package versions or using a container image with pre-installed dependencies for more reproducible and secure builds.

Suggested change

	run: sudo apt install --no-install-recommends --yes libhwloc-dev nvidia-cuda-toolkit ocl-icd-opencl-dev
	run: sudo apt install --no-install-recommends --yes libhwloc-dev=2.4.1-1 nvidia-cuda-toolkit=11.5.2-1 ocl-icd-opencl-dev=2.2.12-2

[BigLep]

I added @FilOzzy to proofs-crate-owners.
I created a scoped token:

I added an organizational secret: https://github.com/organizations/filecoin-project/settings/secrets/actions/FILOZZY_CI_CARGO_PUBLISH_UPDATE_TOKEN

(It looks like there are some potential Copilot comments to look at too.)

[BigLep]

Suggested change

	CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }}
	CARGO_REGISTRY_TOKEN: ${{ secrets.FILOZZY_CI_CARGO_PUBLISH_UPDATE_TOKEN }}

I debated about the name here, but I thought best to make this an organizational token at which point CARGO_REGISTRY_TOKEN would be too broad for the organization.

[rvagg]

@galargh did you see this recently from crates.io? https://crates.io/docs/trusted-publishing (mentioned here filecoin-project/ref-fvm#2185)

[galargh]

@galargh did you see this recently from crates.io? https://crates.io/docs/trusted-publishing (mentioned here filecoin-project/ref-fvm#2185)

Oh yeah! That's really cool :) Thank you for bringing this up! @rvagg would you be able to enable trusted publishing for https://crates.io/crates/filecoin-proofs-api ? It seems like it would be a good testing ground. The name of the workflow is release.yml.

[rvagg]

OK, done, but it was a bit tricky so I'll document here:

• Can't modify a crate's settings as team member, even if that team is supposed to be "owners" - the "Settings" doesn't show up for a crate and none of them show up in my dashboard even though I'm in that owners team. I think that team might just have publish permissions and that's it, can't do cargo owners .. stuff on the CLI either.
• Logged in as filecoin-crate-owner and did the following:

But it resulted in:

Which is a bit odd, I wonder if there's some auth thing that it's not getting right. But I decided not to tinker too much with that account since it's the only one supposedly with owner permission.

• Using that account, I added rvagg as an owner of the crate
• As rvagg I went through the above process and successfully got it added (i.e. it's good to go now)
• Removed rvagg as a crate owner so we're back to where we started wrt permissions.