Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Semantic release #163

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Semantic release #163

wants to merge 2 commits into from

Conversation

greenkiwi
Copy link
Contributor

Description of the change

This shifts to using semantic release for your GitHub release generation.

One requirement is that the comment messages follow conventional-commits formatting.
We tend to remove all "merge" options in our repos - we only allow rebase merges - which results in linear history
image

Once in place - this tooling will automatically generate new semantic versions as well as release notes.

You can see an examples of this here: https://github.com/turo/pre-commit-hooks/releases

You can see where it has called out a breaking change that requires the major version to be incremented:
image

One potential shift you could make would be to split the release action into two pieces:

  • release.yaml -- responsible for creating the new tag/release
  • publish.yaml -- responsible for building assets and addint them to the release.

Type of change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklists

Development

  • Lint rules pass locally
  • The code changed/added as part of this pull request has been covered with tests
  • All tests related to the changed code pass in development
  • Confirm that build/release processes work after merging

Code review

  • This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
  • Jira issue referenced in commit message and/or PR title

Testing

You will need to test and confirm that the workflow works as you expect it to work. I do not plan on creating any "test releases" :)

This adds pre-commit and ci checks to ensure that commit messages follow
[`conventional-commits`](https://www.conventionalcommits.org/en/v1.0.0/).

From their site: Conventional Commits is:
`A specification for adding human and machine readable meaning to commit messages`

Commit messages must follow the following format:
```
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]
```

In general, this means that you will provide a topic:
* feat
* fix
* ci
* refactor

Followed by a description.

Following this standard allows for automatic semantic versioning and
release note generation.

* `.commitlintrc.yaml` - defines the commit message format for linting
* `.cz.json` - configuration for [`commitizen-cli`](http://commitizen.github.io/cz-cli/)
This shifts the release workflow to run after a successful CI run.  It then generates a new semantic
version and then runs the go-releaser on that version.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant