build: switch to release-please and update docs (#2475)

trussworks · Jul 12, 2023 · 02cacea · 02cacea
1 parent 42da85d
commit 02cacea
Show file tree

Hide file tree

Showing 4 changed files with 59 additions and 102 deletions.
diff --git a/.github/workflows/release-please.yml b/.github/workflows/release-please.yml
@@ -0,0 +1,37 @@
+on:
+  push:
+    branches:
+      - main
+  workflow_dispatch:
+
+
+permissions:
+  contents: write
+  pull-requests: write
+
+name: release-please
+
+jobs:
+  release-please:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: google-github-actions/release-please-action@v3
+        with:
+          release-type: node
+          package-name: '@trussworks/react-uswds'
+          release-labels: 'type: release'
+          changelog-types: >
+            { "types":
+              [
+                { "type": "build", "hidden": true },
+                { "type": "chore", "hidden": true },
+                { "type": "ci", "hidden": true },
+                { "type": "feat", "section": "Features" },
+                { "type": "fix", "section": "Bug Fixes" },
+                { "type": "docs", "section": "Documentation & Examples" },
+                { "type": "style", "hidden": true },
+                { "type": "refactor", "hidden": true },
+                { "type": "perf", "section": "Performance Improvements" },
+                { "type": "test", "hidden": true }
+              ]
+            }
diff --git a/docs/contributing.md b/docs/contributing.md
@@ -98,7 +98,7 @@ Because this project exports a library that will be used by other projects, it i
 - [Jest tests](https://jestjs.io/) are run in CI and must pass before the branch can be merged
 - [Happo.io visual regression tests](https://docs.happo.io/docs/reviewing-diffs) are run CI against Storybook stories. All diffs must be approved before the branch can be merged. Developers with access (maintainers and many codeowners) log in to Happo.io account to approve/reject diffs.
 - PR titles must follow conventional commits specification.
-  - We use [`standard-version`](https://github.com/conventional-changelog/standard-version). This auto-generates version numbers and changelog based on commits. We [squash & merge](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#squash-and-merge-your-pull-request-commits) PR commits, so the title must be correct.
+  - We use [release-please](https://github.com/googleapis/release-please). This auto-generates version numbers and changelog based on commits. We [squash & merge](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#squash-and-merge-your-pull-request-commits) PR commits, so the title must be correct.
   - The version number is determined based on the commit prefix -
     **[fix]** indicates a bug fix, **[feat]** indicates a minor bump.
     **[!]** or [BREAKING CHANGES] indicates a major bump. Other

diff --git a/docs/releasing.md b/docs/releasing.md
@@ -2,65 +2,30 @@
 
 Steps for a new release (these are in the process of being automated):
 
-1. Check out `main` and make sure you have pulled down the latest changes and tags
-
-   ```
-   git checkout main
-   git pull --tags
-   ```
-
-2. Determine the version number of the new release
-
-   ```
-   yarn release --dry-run
-   ```
-   You should see output similar to `✔ bumping version in package.json from {old.version.number} to {new.version.number}`. Take note of the `{new.version.number}` which will be used throughout the remainder of release process.
-
-   > :information_source: `yarn release` uses [`standard-version`](https://github.com/conventional-changelog/standard-version) which, combined with adherence to [conventional commits](https://www.conventionalcommits.org/) enforced on main via title linting and using `squash and merge`.
-   [`--dry-run`](https://github.com/conventional-changelog/standard-version#dry-run-mode) logs all of the output and lets you know what `standard-version` *would* do (without actually making changes) so that you can verify that everything aligns with your expectations. 
-   Most importantly, the log will explain how the version number would be bumped, based on new commits to `main`. 
+We use [release-please](https://github.com/googleapis/release-please) github action to automatically create and maintain a release PR. See the [github action documentation](https://github.com/google-github-actions/release-please-action) for details.
 
-3. Create a release branch for the new version to be released, where `{new.version.number}` might be `2.4.1`, for example.
-
-   ```
-   git checkout -b release-{new.version.number} 
-   ```
-
-4. On the newly created release branch, allow `standard-version` to create the release
-
-   ```
-   yarn release
-   ```
-
-   Without using `--dry-run`, `standard-version` will commit the following changes with the message `chore(release): {new.version.number}`:
-   - Bump the version in `package.json`
-   - Generate a new entry in `CHANGELOG.md` with the version, release notes, and today's date.
+1. Release please will open a PR with the change log and version number updated. See [open PRs](https://github.com/trussworks/react-uswds/pulls)
 
-5. Push the changes to Github
+2. If the changes look good and you are ready to perform a release approve the PR.
 
-   ```
-   git push -u origin release-{new.version.number}
-   ```
-
-6. Open a PR for the release branch against `main`
-
-   - PR title should be `chore(release): <version>`
-   - PR should have the github label [type: release](https://github.com/trussworks/react-uswds/issues?q=label%3A%22type%3A+release%22+).
-   - Paste the the changelog generated by `standard-version` in the PR description/body.
-   - Ask for approvals from stakeholders, perform testing on applications, etc.
-     - It can be helpful to reviewers to provide a diff of all the files that have changed since the last release. To do this, add a compare link as a comment to the PR, or in the description/body:
-       `https://github.com/trussworks/react-uswds/compare/{previous.release.tag}...release-{new.version.number}`
+   - The PR for the release branch against `main` will look like this
+     - PR title should be `chore(release): <version>`
+     - PR should have the github label [type: release](https://github.com/trussworks/react-uswds/issues?q=label%3A%22type%3A+release%22+).
+     - Have the changelog generated by `release-please` in the PR description/body.
+     - You can approve or Ask for approvals from stakeholders
+       - It can be helpful to reviewers to provide a diff of all the files that have changed since the last release. To do this, add a compare link as a comment to the PR, or in the description/body:
+         `https://github.com/trussworks/react-uswds/compare/{previous.release.tag}...release-{new.version.number}`
 
    ![image](./release_PR.png)
 
-7. Once the release PR is approved and merged, complete the release by publishing the new version
+3. Once the release PR is approved and merged, complete the release by publishing the new version
 
-   - Create a [**new release**](https://github.com/trussworks/react-uswds/releases/new) on Github, pointed at the merge commit of the release PR.
-     - Set the tag to the version number.
-     - Title your release with the version number. Use the same release notes as the release PR.
-     - Point the release tag at the release merge commit by selecting `Recent Commits` from the `Target` dropdown in the Github UI. You should find the `chore(release): ...` commit at or near the top.
+   - `release-please` will tag and create a release in github automatically so the following should not be necessary. But if you can't wait it can be created manually.
+     - Create a [**new release**](https://github.com/trussworks/react-uswds/releases/new) on Github, pointed at the merge commit of the release PR.
+       - Set the tag to the version number.
+       - Title your release with the version number. Use the same release notes as the release PR.
+       - Point the release tag at the release merge commit by selecting `Recent Commits` from the `Target` dropdown in the Github UI. You should find the `chore(release): ...` commit at or near the top.
    - Download the tarball for the release from the Github Action workflow
-
      - After merging the release PR, a [Github Actions workflow](../.github/workflows/package-release.yml) will build and package the release. You can find the action in the list by [filtering for `Package release` actions](https://github.com/trussworks/react-uswds/actions/workflows/package-release.yml?query=is%3Asuccess). From the bottom of the workflow run's summary page, there is an artifacts section [where the artifact can be downloaded](https://github.com/actions/upload-artifact#where-does-the-upload-go).
      - The `.tgz` will be inside of the `artifact.zip`.
 
@@ -82,7 +47,6 @@ Steps for a new release (these are in the process of being automated):
      npm publish <tarball>
      ```
      
-     
      - `<tarball>` should point to the `.tgz` obtained in the previous step.
      - You will be prompted for a MFA code.
      - You may need to `npm login` first.
@@ -108,3 +72,8 @@ Steps for a new release (these are in the process of being automated):
    - **Rebuild app from scratch** - remove `node_modules` and run `yarn`, `yarn build`. If any errors occur, stop here.
    - **Publish the new package to npm** - `npm publish`.
  </details>
+
+## Resources
+
+- [release-please home](https://github.com/googleapis/release-please)
+- [release-please github action documentation](https://github.com/google-github-actions/release-please-action)
diff --git a/package.json b/package.json
@@ -31,7 +31,6 @@
     "lint": "tsc && eslint --ext js,jsx,ts,tsx src && stylelint \"src/**/*.{css,scss}\"",
     "format:check": "prettier --check \"src/**/*.{js,jsx,ts,tsx,css,scss,json,md}\"",
     "format:fix": "prettier --write \"src/**/*.{js,jsx,ts,tsx,css,scss,json,md}\"",
-    "release": "standard-version -t ''",
     "prepare": "yarn build",
     "prepublishOnly": "yarn test && yarn lint",
     "happo": "happo",
@@ -109,7 +108,6 @@
     "sass-loader": "^13.0.0",
     "sass-resources-loader": "^2.0.1",
     "source-map-loader": "^4.0.1",
-    "standard-version": "^9.0.0",
     "style-loader": "^3.2.1",
     "stylelint": "^13.3.0",
     "stylelint-config-css-modules": "^2.2.0",
@@ -130,52 +128,5 @@
     "glob-parent": "5.1.2",
     "trim": "0.0.3",
     "trim-newlines": "3.0.1"
-  },
-  "standard-version": {
-    "skip": {
-      "tag": true
-    },
-    "types": [
-      {
-        "type": "build",
-        "hidden": true
-      },
-      {
-        "type": "chore",
-        "hidden": true
-      },
-      {
-        "type": "ci",
-        "hidden": true
-      },
-      {
-        "type": "feat",
-        "section": "Features"
-      },
-      {
-        "type": "fix",
-        "section": "Bug Fixes"
-      },
-      {
-        "type": "docs",
-        "section": "Documentation & Examples"
-      },
-      {
-        "type": "style",
-        "hidden": true
-      },
-      {
-        "type": "refactor",
-        "hidden": true
-      },
-      {
-        "type": "perf",
-        "section": "Performance Improvements"
-      },
-      {
-        "type": "test",
-        "hidden": true
-      }
-    ]
   }
 }