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

[Wulf]

Yes, exactly -- and that's the next step we should automate.

I think we can achieve this with semantic-release and something like https://github.com/peter-evans/create-pull-request.

[hasezoey]

because of some discussions, i would like to do this somewhat soon (hopefully releasing 0.1.0 in the process or before), so i will sum up what needs to be done and in which ways we will likely do it (roughly organized in the order things need to be done):

• consistent commit message styles (add a section to CONTRIBUTING and enforce it in PRs via manual review)
  • enforce commit styles on commit via hooks? (would require additional user installation)
  • enforce commit message style as a PR workflow?
• automatic release commits (manually triggered workflow)
  • automatic decision what version to choose? (when to go for major, minor and patch)
  • automatic changelog generation (conventional-changelog would require nodejs in the CI and consistent commit messages)
  • choose what release workflow to use:
    • create a release PR with create-pull-request (likely requires manual tag generation and separate publishing)
    • use semantic-release (requires nodejs, but only in the CI)
• automatic publishing
  • on github
  • on crates.io

@Wulf what do you think about those steps, any ideas on what should / could be used?
i personally would go for semantic-release, as i am already familiar with it, but it would require some nodejs setup, but actual nodejs installation would only be required in the CI and those who update the nodejs dependencies - manually triggered as shown above (this would solve the issues of "automatic version decision", "changelog generation" and "publishing")

[hasezoey]

i will re-open it issue for now, until 0.1.0 is released and dry_run: true is removed from the publishing step

[Wulf]

hey @hasezoey :)

Thanks for your patience here, I've been busy moving! I hope everything has been well on your end.

I saw the generated Changelog in your PR and it looks great! I think it's okay if we remove the dry_run: true and start using the pipeline.

[hasezoey]

I saw the generated Changelog in your PR and it looks great! I think it's okay if we remove the dry_run: true and start using the pipeline.

as long as 0.1.0 is not released, i dont recommend removing dry_run for 2 reasons:

1. 0.1.0 changelog is currently already manually written
2. semantic release does not support 0.X.X versions as i have come to know*

*semantic release treats major number 0 like any other number, meaning it will release according to the minor, major and patch rules and so (in our case) if we have feat: something it will release a new minor version (x.X.0) and if we have a BREAKING CHANGE commit, it will release a major version (X.0.0) instead of just incrementing the minor for zero based versions (0.1.0 -> 0.2.0, semantic will do 0.1.0 -> 1.0.0 on BREAKING CHANGE);
the example changelog provided in my PR worked because there was no BREAKING CHANGE in the history it parsed

TL;DR: semantic-release will do:
0.1.0 + feat: = 0.2.0
0.1.0 + fix = 0.1.1
0.1.0 + BREAKING CHANGE = 1.0.0