cargo-bins/release-pr

GitHub Action to create a release PR using cargo-release — soft deprecated: try release-plz instead!

release-pr's Issues

Support for releasing all crates in the workspace

For projects with a large number of crates per repository, it would be very useful to have an option to run cargo release from workspace root, so that the version for each crate is bumped consistently across the repo (this also helps with tag management, since we don't want to have a separate tag for each single crate).
Do you think this is something that could be supported by release-pr action? It'd then fit my usecase quite well.

Sign commits with sigstore and github's OIDC

https://blog.chainguard.dev/gitsign-github-actions/

Even if the signatures won't be verified from GitHub's point of view at the moment

Meaning of "The action sets the following"

What does this actually mean, where is it set?

I guess especially version would be useful - ideally once a PR is merged, another action is triggered to actually publish the crates with the version that was just merged.

Do you perhaps have a workflow example where you're also automating this action of publishing to crates.io, and if so could you share please?

Release branches are not created

I am not sure what I am doing wrong here: https://github.com/matthiasbeyer/test-cargo-release-pr-action/actions/runs/3583677179/jobs/6029394637

Thankfully I tried this on a testing repository 😄

Support custom options to `cargo release`

I'd like to be able to use cargo release with the --dependent-version fix option.

Context: When releasing all crates from a workspace at once (related to #53), there are some dependencies between the crates (and circular dev-dependencies, with this workaround for now), and bumping dependent versions breaks the build. Concrete example: arkworks-rs/algebra.

I understand that not all options can be supported, else the action would break, but I think this is an option that shouldn't affect the result.

Doesn't support repos with no Cargo.lock

We may need to use cargo metadata instead of cargo pkgid

Use `cargo-semver-checks` to verify the update does not break semver

I'm currently in the process of opening new release prs on cargo-binstall and I just realize that calling cargo-semver-checks in release-pr can automate the job of maintaining semver without having to run the command locally or potentially forgetting about this.

Concept of base-branch

I'm not fully sure I get the idea of base-branch.
From the docs I understood that the PR will be done againast base-branch.
Example: In my release process, I'd like to make the release PR against a branch called releases, and in the second step publish tags & crates from releases branch. Therefore, I've set base-branch: releases, but either it is not working as expected, or I misunderstood its purpose.
See this example PR, and the corresponding workflow.

Document permissions

In the example workflow, I see

permissions:
  id-token: write # Enable OIDC
  pull-requests: write
  contents: write

and

github-token: ${{ secrets.GITHUB_TOKEN }}

Yet nothing tells me what the token is for and which scopes it is supposed to have.

When I run the workflow, I get

Error: GitHub Actions is not permitted to create or approve pull requests.

so apparently it doesn’t use the pull-requests: write permission? Why?

Actions don't run on created PR

This is a known issue with GHA, see here for a number of workarounds: https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#triggering-further-workflow-runs

As a simple workaround that involves a bit of work, the generated branch can be locally checked out, the commit amended, and then force-pushed to the remote again.

It would be nice to handle this in this action, though.