Skip to content

Integrating a semantic-release like process appears to be fairly challenging #2217

@ryanobjc

Description

@ryanobjc

I'm fairly fond of semantic release, from git message analysis. It prevents devs from having to guess, and it allows us to issue versions frequently, specifically pre-release versions. This means our dev environment can be updated with prerelease artifacts and we can manage dev as well as prod.

I've been using knope to manage versions. My prototype worked but it had 2 particular problems:

  • every single release triggered a commit (this is knope in action), all it did was change Cargo.toml
  • I had to let knope create the release, since there's no other way to trigger a tag from another gh action

Basically I'm unable to use/compose the cargo-dist workflow because it can only be triggered by creating a tag. And github bans
tag workflow dispatches when the tag is created/pushed by a robot (either the workflow default secret, or custom app secrets).

I could potentially just continue to use the 'create a release'. But if I could workflow_call into the cargo-dist from my
knope/semantic-versioning step, then I'd also be a happy camper.

What are people doing to integrate a semantic release auto-versioning and cargo-dist? This feels unwieldy now, and I've spent a day hitting my head on endless github action limitations that are not documented.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions