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

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.

Start by reviewing the cargo-dist workflow, the knope/semantic-versioning step, and GitHub Actions' tag-trigger and workflow_call behavior described in the issue. Done would mean defining a supported integration path for automatic prerelease versioning and cargo-dist without the documented tag-trigger limitations.

Written by the indexing model from the issue text.