chore: add release-please

.github/workflows/release-please.yml

@@ -0,0 +1,17 @@
+name: release-please
+on:
+  push:
+    branches:
+      - master
+jobs:
+  release-please:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: GoogleCloudPlatform/release-please-action@v2
+        id: release
+        with:
+          # We can't rely on the GITHUB_TOKEN as we need to trigger
+          # further actions and the GITHUB_TOKEN doesn't allow it
+          token: ${{ secrets.NODE_PKG_RELEASE_TOKEN }}
+          release-type: node
+          package-name: '@netlify/open-api'

.github/workflows/swagger-bump.yml

@@ -0,0 +1,20 @@
+name: swagger-bump
+on:
+  # Workaround for bumping the swagger.yml file on release-please PRs
+  push:
+    branches:
+      - release-*
+jobs:
+  swagger-bump:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v1
+        with:
+          node-version: 12
+          registry-url: 'https://registry.npmjs.org'
+      - run: npm ci
+      - run: npm version:1-swagger
+      - uses: stefanzweifel/git-auto-commit-action@v4
+        with:
+          commit_message: "chore: bump swagger.yml file"

CONTRIBUTING.md

@@ -32,17 +32,18 @@ You may first want to edit swagger.yml to add your field or endpoint definitions
 
 ## Making PRs
 
-1. Don't bump the version number for `swagger.yml` changes. Do that during the release process.
-2. Ensure `make validate` passes.
-3. The go tests run against the last generated go client. These must pass before making a release.
-4. If all you want is a new endpoint, you can PR just the `swagger.yml` changes for review and regenerate the go client when its ready to go in.
+1. Make sure your PR title and commits follow the [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/) spec.
+2. Don't bump the version number for `swagger.yml` changes. The release process handles that.
+3. Ensure `make validate` passes.
+4. The go tests run against the last generated go client. These must pass before making a release.
+5. If all you want is a new endpoint, you can PR just the `swagger.yml` changes for review and regenerate the go client when its ready to go in.
 
 ## Making a new release
 
-1. Make sure you are on the HEAD of the master branch.
-2. regenarate go client (if you haven't) (Make all and commit the results)
-3. bump a JS package version with `npm version [major|minor|patch]` (updates package.json, swagger.yaml and create a git tag)
-4. Run `npm publish` which will as `git push && git push --tags` to push to the origin, create a github release and publish the spec to npm.
+1. Merge the release PR (auto generated via `release-please`).
+2. Switch to the default branch git checkout master.
+3. Pull latest changes git pull.
+4. Run `npm publish`.
 
 ## License
 

package.json

@@ -17,7 +17,6 @@
   "devDependencies": {
     "analytics": "^0.2.0",
     "analytics-plugin-ga": "^0.1.5",
-    "auto-changelog": "^1.16.1",
     "ava": "^2.4.0",
     "cp-file": "^7.0.0",
     "eslint": "^6.3.0",
@@ -58,8 +57,7 @@
     "convert": "node src/convert.js",
     "version": "run-s version:*",
     "version:1-swagger": "node src/bump-swagger.js",
-    "version:2-changelog": "auto-changelog -p --template keepachangelog --breaking-pattern breaking",
-    "version:3-git": "git add CHANGELOG.md swagger.yml",
+    "version:2-git": "git add swagger.yml",
     "redoc": "node src/docs/build.js",
     "lint": "run-s eslint prettier",
     "eslint": "eslint --fix \"src/**/*.js\"",