Publishing via CI

[Wulf]

hey @hasezoey

Do you have any experience setting up crates.io publishing CI? I think it’s time for us to pursue this. I can add a CARGO_TOKEN secret to this repo which we can use for authorization.

Anyway, hope all is well on your end 🙌

[hasezoey]

Do you have any experience setting up crates.io publishing CI?

yes, but only one rust package, and that was via semantic-release, a nodejs package (package in question is new-string-template), aside from that i also use it in some nodejs-only packages

[Wulf]

Found this https://github.com/cycjimmy/semantic-release-action for publishing crates, but I don’t know if it’ll generate the changelog from our conventional commit messages

[hasezoey]

but I don’t know if it’ll generate the changelog from our conventional commit messages

it is basically a wrapper around semantic-release to have it as a action, you will still need the same configuration

---

if we will use automated releases, then we should enforce commit message style (conventional commits?) so that everything is actually included

[Wulf]

hey @hasezoey, I've given this a first attempt -- pushing to the release branch will automatically publish the crate. No automatic changelog generation or version bumping.

I'm suggesting the following workflow for us:

• continue development on main as usual
• create a CR like chore(CHANGELOG.md): add all changes since 0.0.16 #69 which updates the CHANGELOG and Cargo.toml/Cargo.lock file with an appropriate version (this CR should target main -> release)
• review and merge in to publish

Let me know what you think -- it's a step closer to what we were discussing above.

[hasezoey]

should be merged back like release -> main after a release, if yes, with merge commits or fast forward-only?

[hasezoey]

from what i can tell, 2 versions have been published, without any release commit or notice in the changelog, namely 0.0.17 and 0.0.17-alpha, maybe they should be yanked, or the changelog needs to be updated

crates.io versions

[Wulf]

hey @hasezoey, hope all is well :)

I made the mistake of using version 0.0.17 for testing the publishing CI. I used 0.0.17-alpha as well for testing.

[Wulf]

should be merged back like release -> main after a release, if yes, with merge commits or fast forward-only?

Sorry, I think I didn't explain correctly. Here's a scenario:

1. New feature PR in new-feature-branch
2. Review new-feature-branch and merge into main
3. Repeat steps 1-2 until we're ready to release.
4. Create main->release PR which updates Cargo.toml/Cargo.lock version + adds CHANGELOG entries
5. Merge main into release (fast-forward only) -- this will kick the publishing CI

Notes:

• We can work on making step 4 more automated but I didn't have time to automate this.
• Step 5 will publish to crates.io automatically but it requires either you or me to approve the main -> release PR before merging it in.

[Wulf]

I'm going to close this issue but feel free to continue the discussion. The next step for publishing CI is to automate the versioning and changelog generation with something like semantic-release. I gave it a shot but didn't have time to complete it.

[hasezoey]

if we use semantic-release, then it will automatically create the changelog, github release, github tag and github release commit, so it would be good to merge it back if that is only created on the release branch so that we dont get diverging branches, otherwise i think it will just continue to work on main without release commits, but we would need to use merge commits to merge into release and the git tags and release commits would only exist on the release branch and so going through the history (like bisect or something else) quite annoying

[Wulf]

hey @hasezoey, I read your concern above and wanted to propose a new flow:

• Continue developing on the main branch as usual
• When ready, manually trigger a release like so:

out2.mp4

Thoughts?

[hasezoey]

Thoughts?

sure, though we (or i) need to remember to actually do the changelog and a version commit and tag it