feat: add semantic-release.

.github/workflows/release.yml

@@ -0,0 +1,29 @@
+name: Release
+on:
+  push:
+    branches:
+      - master
+jobs:
+  release:
+    name: Release
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v1
+      - name: Setup Node.js
+        uses: actions/setup-node@v1
+        with:
+          node-version: 12
+      - name: Cache
+        uses: actions/cache@v1
+        with:
+          path: ~/.npm
+          key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
+          restore-keys: |
+            ${{ runner.os }}-npm-
+      - name: Install dependencies
+        run: npm ci
+      - name: Release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}
+        run: npx semantic-release

.releaserc.js

@@ -0,0 +1,63 @@
+'use strict';
+
+/* The releaseConfig object drives configuration across 5 semantic-release plugins.  For more details on the
+plugin options and overides used see:
+- @semantic-release/commit-analyzer: https://github.com/semantic-release/commit-analyzer
+- @semantic-release/release-notes-generator: https://github.com/semantic-release/release-notes-generator
+- @semantic-release/changelog: https://github.com/semantic-release/changelog
+- @semantic-release/npm: https://github.com/semantic-release/npm#semantic-releasenpm
+- @semantic-release/git: https://github.com/semantic-release/git
+- @semantic-release/github: https://github.com/semantic-release/github
+*/
+
+const typesForPatch = ['docs', 'style', 'refactor', 'perf'];
+const parserOpts = {
+        noteKeywords: ['BREAKING CHANGE', 'BREAKING CHANGES', 'BREAKING']
+    }
+
+const releaseConfig = {
+    branches: [
+        'master'
+    ],
+    plugins: [
+        [
+            '@semantic-release/commit-analyzer',
+            {
+                releaseRules: [
+                    ...typesForPatch.map((type) => ({
+                        type,
+                        release: 'patch'
+                    }))
+                ],
+                parserOpts
+            }
+        ],
+        [
+            '@semantic-release/release-notes-generator',
+            {
+                parserOpts
+            }
+        ],
+        '@semantic-release/changelog',
+        [
+            '@semantic-release/npm',
+            {
+                npmPublish: false
+            }
+        ],
+        [
+            '@semantic-release/git',
+            {
+                assets: [
+                    'package.json',
+                    'package-lock.json',
+                    'CHANGELOG.md'
+                ],
+                message: 'chore(release): ${nextRelease.version} \n\n${nextRelease.notes}'
+            }
+        ],
+        '@semantic-release/github'
+    ]
+};
+
+module.exports = releaseConfig;

.travis.yml

@@ -3,9 +3,6 @@ node_js:
   - 8
   - 10
   - 12
-cache:
-  directories:
-    - node_modules
 
 script:
   - npm run lint

README.md

@@ -133,4 +133,4 @@ Shepherd is written in TypeScript, which requires compilation to JavaScript. Whe
 
 Shepherd currently has minimal test coverage, but we're aiming to improve that with each new PR. Tests are written with Jest and should be named in a `*.test.ts` alongside the file under test. To run the test suite, run `npm run test`.
 
-We use [TSLint](https://github.com/palantir/tslint) to ensure a consistent coding style and to help prevent certain classes of problems. Run `npm run lint` to run the linter, and `npm run fix-lint` to automatically fix applicable problems.
+We use [TSLint](https://github.com/palantir/tslint) to ensure a consistent coding style and to help prevent certain classes of problems. Run `npm run lint` to run the linter, and `npm run fix-lint` to automatically fix applicable problems.

docs/releasing.md

@@ -1,8 +1,16 @@
 # Releasing Shepherd
 
-Shepherd uses [Travis CI](https://travis-ci.org/) for continuous integration to run tests and linters automatically when changes are pushed. Travis is also set up to automatically publish new versions of Shepherd to npm when new tags are pushed to GitHub.
+Shepherd uses [semantic-release](https://github.com/semantic-release/semantic-release), GitHub workflows, and [Travis CI](https://travis-ci.org/) to fully automate releases.  
+
+Every merge to master triggers a GitHub workflow which culminates in a new tag. Every new tag triggers a Travis CI job which culminates in the new tagged version of Shepherd being published to npm.
+
+## semantic-release
+- CHANGELOG updates made via [@semantic-release/changelog](https://github.com/semantic-release/changelog)
+- Release Notes compiled via [@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator)
+- Tagging based on commit message via [@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer)
+  - Commits that contain `BREAKING CHANGE`, `BREAKING CHANGES`, or `BREAKING` in their body will be considered breaking changes.
+  - Commits with a `docs`, `style`, `refactor`, or `perf` type will be associated with a patch release.
+  - If a commit doesn't match any of the above rules, it will be evaluated against the [default release rules](https://github.com/semantic-release/commit-analyzer/blob/master/lib/default-release-rules.js).
+
+Note: `semantic-release` depends on `GH_TOKEN` only as part of CI/CD. Users need not set this token to use Shepherd.
 
-1. Move any changes under the "Upcoming" heading in `CHANGELOG.md` to a new header based on the upcoming version name.
-1. Use `npm version [patch|minor|major]` to create a new version. This command will update the version in `package.json`, commit the changes, and tag it with the corresponding `vX.Y.Z` name.
-1. Run `git push origin vX.Y.Z` to push the new tag to GitHub. This will kick off a new job on Travis, and the new version will be published automatically if all tests pass.
-1. Once the Travis job finishes, create a new release on GitHub based on the new tag. Include the corresponding entries from the changelog in the release description.