build: semantic release

.github/workflows/release.yml

@@ -0,0 +1,27 @@
+name: Release
+on:
+  push:
+    branches:
+      - main
+      - next
+
+jobs:
+  release:
+    if: "!contains(github.event.head_commit.message, '[skip release ci]')"
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v3
+        with:
+          fetch-depth: 0
+      - name: Setup Node.js
+        uses: actions/setup-node@v3
+        with:
+          node-version: 16
+      - name: Install dependencies and build TS
+        run: npm ci && npm run build
+      - name: Release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
+        run: npx semantic-release

.husky/commit-msg

@@ -0,0 +1,4 @@
+#!/bin/sh
+. "$(dirname "$0")/_/husky.sh"
+
+npx commitlint --edit $1

.releaserc.yml

@@ -0,0 +1,21 @@
+branches: [main, next]
+plugins:
+  - '@semantic-release/commit-analyzer'
+  - ['@semantic-release/release-notes-generator', { 'writerOpts': { 'commitsSort': ['subject', 'scope'] } }]
+  - '@semantic-release/changelog'
+  - [
+      '@semantic-release/git',
+      {
+        # TODO: once docker builds are a thing, we're going to have to manually add the assets
+        # since we're also updating the action.yml file with every release!
+        # Uncomment this line below once those changes are live:
+        # assets: ['action.yml', 'CHANGELOG.md', 'package.json', 'package-lock.json'],
+        message: "build(release): 🚀 v${nextRelease.version} 🦉\n\n${nextRelease.notes}\n[skip release ci]",
+      },
+    ]
+  # `npm` must be after `git` because we need the `prepare`step of the `git` plugin
+  # to execute first so it can create the build commit since we do some add'l tagging
+  # in the `postversion` npm hook
+  - '@semantic-release/npm'
+  # Lightweight alternative to `@semantic-release/github` that creates a draft release
+  - ['@semantic-release/exec', { 'publishCmd': 'gh release create ${nextRelease.version} --draft --generate-notes' }]

CHANGELOG.md

@@ -1,3 +1,53 @@
+# [8.6.0-next.6](https://github.com/readmeio/rdme/compare/v8.6.0-next.5...v8.6.0-next.6) (2023-02-13)
+
+
+### Bug Fixes
+
+* run tests but NOT release workflow on release commits ([24f885e](https://github.com/readmeio/rdme/commit/24f885e00cf966d32cca013ca59aea903f9c3807))
+* try this as an alternative to @semantic-release/github ([8c343a0](https://github.com/readmeio/rdme/commit/8c343a09bbfa62e2410705d480b91837ec2af854))
+
+
+### Reverts
+
+* Revert "chore: remove github release npm script" ([e77b67a](https://github.com/readmeio/rdme/commit/e77b67a0c03075e5a78de464ceb4873e1354579d))
+* don't set header for changelog ([194489e](https://github.com/readmeio/rdme/commit/194489ee5382c0366606c7d62b45262783b91394))
+
+## What's Changed
+
+### Bug Fixes
+
+* try rearranging steps like this ([cac0c1d](https://github.com/readmeio/rdme/commit/cac0c1df2b71d6e15b7c418628708d2490cc1986))
+
+
+### Reverts
+
+* Revert "feat: drop duplicative tag" ([f9fe6c6](https://github.com/readmeio/rdme/commit/f9fe6c6cf92cb944ac284b4bed4077e9d63662cc))
+
+## What's Changed
+
+### Bug Fixes
+
+* reformat header again ([bd2e1a2](https://github.com/readmeio/rdme/commit/bd2e1a24122a2e40e0944eae638d02f205165fd9))
+
+
+### Features
+
+* drop duplicative tag ([4c34207](https://github.com/readmeio/rdme/commit/4c34207be6acf3b30b6f0b9e3b70722047f52403))
+
+## What's Changed in 8.6.0-next.3
+
+### Bug Fixes
+
+* rebuild prior to npm publish ([29b9ec6](https://github.com/readmeio/rdme/commit/29b9ec6a38212882de22f9c3c4f35e5ce295f267))
+* reformat github release header ([38c5625](https://github.com/readmeio/rdme/commit/38c5625bb2a22506953943a389f05ff70b39d659))
+
+# [8.6.0-next.2](https://github.com/readmeio/rdme/compare/v8.6.0-next.1...v8.6.0-next.2) (2023-02-10)
+
+
+### Features
+
+* add git + changelog plugins ([85e4bfd](https://github.com/readmeio/rdme/commit/85e4bfd982d1b9d9193ccf2c5441eb6aa016b725))
+
 ## 8.5.0 (2023-02-01)
 
 * docs: update outdated file names ([52a8219](https://github.com/readmeio/rdme/commit/52a8219))
@@ -1435,6 +1485,3 @@ Alongside this change, this release includes major documentation updates and sup
 * version 0.1.2 ([349ba96](https://github.com/readmeio/rdme/commit/349ba96))
 * Weight help items ([fffc107](https://github.com/readmeio/rdme/commit/fffc107))
 * Whoops, fixing up api url and making it work ([da021fd](https://github.com/readmeio/rdme/commit/da021fd))
-
-
-

MAINTAINERS.md

@@ -1,46 +1,42 @@
 # Maintainers
 
-This doc describes how to prep a release and publish to GitHub and `npm`.
+This doc describes how releases are published to GitHub and `npm`.
 
-## Prep the Release
+## Automatic Packaging + Publishing 📦
 
-Run the following command, where `<version>` is the version you wish to update the package to:
+Nearly all of our release process is automated. In this section, we discuss everything that takes place!
 
-```sh
-npm run bump -- <version>
-```
+> **Note**
+> You don't _need_ to know everything that takes place here, this is mostly for my own documentation purposes! But if you are tagging an actual release, there are a couple of outstanding steps that are described in [the next section](#one-more-thing-☝️) 👇
 
-This command will automatically bump the version in the `package.json` and the `package-lock.json` files, update [`CHANGELOG.md`](./CHANGELOG.md), and add the corresponding git tags.
+When code is merged into the `main` or `next` branches, a release workflow (powered by [`semantic-release`](https://github.com/semantic-release/semantic-release)) automatically kicks off that does the following:
 
-## Publishing to GitHub :octopus:
+- All commit messages since the last release are analyzed to determine whether or not the new changes warrant a new release (i.e., if the changes are features or fixes as opposed to smaller housekeeping changes) 🧐
+- Based on the changes, the version is bumped in [`package.json`](./package.json) with a new git tag 🏷️ For example, say the current version is `8.5.1` and the commit history includes a new feature. This would result in a minor semver bump, which would produce the following tags:
+  - A release tag like `v8.6.0` if on the `main` branch
+  - A prerelease tag like `v8.6.0-next.1` if on the `next` branch
+- A changelog is generated and appended to [`CHANGELOG.md`](./CHANGELOG.md) 🪵
+- A build commit (like [this](https://github.com/readmeio/rdme/commit/533a2db50b39c3b6130b3af07bebaed38218db4c)) is created with the updated `package*.json` and `CHANGELOG.md` files 🆕
+- A couple duplicated tags are created for the current commit so our users can refer to them differently in their GitHub Actions (e.g., `8.6.0`, `v8`) 🔖
+- The new commit and tags are pushed to GitHub 📌
+- The new version is published to the `npm` registry 🚀 The package [distribution tag](https://docs.npmjs.com/adding-dist-tags-to-packages) will depend on which branch is being pushed to:
+  - If on the `main` branch, a version is pushed on the main distribution tag (a.k.a. `latest`, which is used when someone runs `npm i rdme` with no other specifiers).
+  - If on the `next` branch, the prerelease distribution tag (a.k.a. [`next`](https://www.npmjs.com/package/rdme/v/next)) is updated.
+- A [GitHub release is created](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release) for the tag (in draft form) 🐙
 
-The next step is to push these changes to GitHub:
+## One more thing ☝️
 
-```sh
-git push # pushes the code
-git push --tags -f # pushes the tags
-```
+> **Note**
+> The steps in this section are only required if you're building an actual release and not a prelease (i.e., changes are being merged into the `main` branch).
 
-Once the code and tags are pushed to GitHub, [create a new release](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release) so the latest tag is surfaced in [the GitHub Marketplace listing](https://github.com/marketplace/actions/rdme-sync-to-readme).
+While nearly all of our release process is automated, there are a couple quick steps remaining:
 
-Make sure you have the [GitHub CLI](https://cli.github.com) installed and then run the following:
+1. **Backport the changes in the `main` branch back into `next`** 🔙 you can do so by running the following:
 
 ```sh
-npm run release:gh
+git checkout next
+git merge main
+git push
 ```
 
-This will create a draft release which you can enhance before publishing. I like to summarize the changes and note any highlights in a blurb above the auto-generated release notes. These release links are nice for sharing with customers, on socials, etc.
-
-## Publishing to `npm` :rocket:
-
-Finally, publish the changes to `npm`. If you're publishing to a non-standard [distribution tag](https://docs.npmjs.com/adding-dist-tags-to-packages) for prelease purposes or otherwise (e.g., `alpha`, `beta`, `next`, etc.), you can run the following:
-
-```sh
-npm publish --tag <tag>
-```
-
-If you're publishing to the default [distribution tag](https://docs.npmjs.com/adding-dist-tags-to-packages) (i.e., `latest`), you can omit the `--tag` flag like so:
-
-```sh
-npm publish
-```
+2. **Fluff out the GitHub release and publish it** ✍️ the GitHub release is currently in draft form but it needs to be published so the latest version is surfaced to folks that discover our tool via [the GitHub Marketplace listing](https://github.com/marketplace/actions/rdme-sync-to-readme). I like to summarize the changes and note any highlights in a blurb above the auto-generated release notes. These release links are nice for sharing with customers, on socials, etc.