ci: 👷 add auto-release workflow from template

.cz.toml

@@ -0,0 +1,8 @@
+[tool.commitizen]
+version = "0.1.0"
+bump_message = "build(version): :bookmark: update version from $current_version to $new_version"
+version_schema = "semver"
+version_provider = "commitizen"
+update_changelog_on_bump = true
+# Don't regenerate the changelog on every update
+changelog_incremental = true

.github/workflows/release-project.yml

@@ -0,0 +1,21 @@
+name: Release project
+
+on:
+  push:
+    branches:
+      - main
+
+# Limit token permissions for security
+permissions: read-all
+
+jobs:
+  release-project:
+    # This job outputs env variables `previous_version` and `current_version`.
+    # The workflow needs write permissions for `GITHUB_TOKEN` to create a release.
+    permissions:
+      contents: write
+    uses: seedcase-project/.github/.github/workflows/reusable-release-project.yml@main
+    with:
+      app-id: ${{ vars.UPDATE_VERSION_APP_ID }}
+    secrets:
+      update-version-gh-token: ${{ secrets.UPDATE_VERSION_TOKEN }}

CHANGELOG.md

@@ -0,0 +1,16 @@
+# Changelog
+
+Since we follow [Conventional
+Commits](https://decisions.seedcase-project.org/why-conventional-commits),
+we're able to automatically create formal "releases" of the website
+based on our commit messages. Releases in the context of websites are
+simply snapshots in time of the website content. We use
+[Commitizen](https://decisions.seedcase-project.org/why-semantic-release-with-commitizen)
+to automatically create these releases using
+[SemVer](https://semverdoc.org) as the version numbering scheme.
+
+Because releases are created based on commit messages, a new release is
+created quite often---sometimes several times in a day. This also means
+that any individual release will not have many changes within it. Below
+is a list of the releases we've made so far, along with what was changed
+within each release.