[Chore] Introduce a release workflow about clarinet HOT 13 CLOSED

I think we want 3 different workflows for this project.

@lgalabru I think I can tie this all into one workflow to reduce code duplication in a way that's simple enough and makes sense, otherwise there'd be a good amount of copy pasta between the 3 of them.

from clarinet.

Thinking more about this, I can see a world where we stage, test features and prepare releases.
So maybe more something like a git flow. Any thoughts @agraebe?

from clarinet.

yeah, that would be great. Clarinet will become one of the first things devs are exposed to and it would be great to ensure we test before releasing a new version to everyone. I'll let engs chime in on the git-flow - one idea might be to have a staging branch and by default merge PRs into that one. On a regular cadence (after testing), we could merge staging into master and kick-off a release

from clarinet.

Found a way around the signing issue, so it's not needed. But it seems clarinet is still not notable enough to be submitted to the homebrew-core:

GitHub repository not notable enough (<30 forks, <30 watchers and <75 stars)

from clarinet.

Related #1

from clarinet.

Windows packages will be blocked by #35

from clarinet.

Additional requests: ideally, when running the CI, we try to build some binaries for macOS / linux / windows, and we also try to execute clarinet test in the examples/counter, to make sure that the binary is functional on the different platforms.

from clarinet.

We have a few issues that we can put under the umbrella of this epic, so I'll try to clarify the needs.

I think we want 3 different workflows for this project.

1. When opening a pull request, we want to make sure that:
   a) cargo build runs on Mac / Windows / Linux
   b) cargo test exits with status code 0
   c) We also want to make sure that the build obtained during step a) is working. To achieve that we can run clarinet test in examples/counter, and see if it exits with status code 0

2. When merging a Pull request to master
   All of the steps from 1) and:
   a) produce and push a docker image, tagged as bleeding_edge

3. When releasing a new version (we can go with a manual trigger for now)
   All of the steps from 1) and
   a) Attach artifacts to the release, ideally as many os / architectures possible (arm, x86, m1, etc)
   b) Kudos for life: produce some manifests for top 3-5 package managers - homebrew, winget, apt, etc.

from clarinet.

When releasing a new version (we can go with a manual trigger for now)

@lgalabru Would you want automated releases upon merges into master, similar to how the API is configured? With this, the version would be incremented based on the commit comments following the conventional commits spec:
https://www.conventionalcommits.org/en/v1.0.0/#summary

from clarinet.

I'll let engs chime in on the git-flow

Not sure who else is watching this issue. cc @reedrosenbluth @kantai

From my perspective git-flow with a staging branch makes sense. To stick to git-flow canonical norms, I would suggest naming the staging branch develop, similar to how the stacks-blockchain does it, except the versioning will be handled automatically once merged into master for clarinet. A changelog will also be auto-generated.

It's important that we stick to conventional commits messages -- once you're doing it for a while it becomes second-nature, even in repos that don't require it. It's good hygiene to have a basic comment structure anyways. To help with this, I've installed a pre-commit git hook to run commitlint and verify that the dev's commit message aligns with the convention:

from clarinet.

Works for me.

the versioning will be handled automatically once merged

The version will be bumped manually, correct?

from clarinet.

The version will be bumped manually, correct?

No, with this setup it will be versioned automatically. semantic-release analyses the commit messages since the last release and determines the next version based on semver principles. Its goal is to remove the romanticism around version numbers and make it more systematic.

So a commit with the message "fix: removed a bug" will increment the PATCH number once merged to master, and a commit with the message "feat: added cool spinner" will increment the MINOR number once merged to master. The full list of acceptable headers and what they do is defined in the conventional commits spec.

Since this process adds more importance to the commit messages, it might make sense to use the squash and merge method when merging a PR into the develop branch. This will allow you to write a new commit message resulting from the squash, and give you greater control over the commit messages which will ultimately make their way into the master branch.

I will also setup a GH action which will inform you on what the new version will be if a PR for develop -> master is merged so it isn't so much of a surprise.

from clarinet.

@lgalabru In order for package managers like brew to work, we're also going to need to sign + notarize the clarinet app. I think it would be best to do this in a separate issue/PR, because I'm not familiar how to do that with a Rust project yet.

from clarinet.