feat: configure release

This reverts commit 1a8c378.
dialpad · Aug 11, 2022 · 6289700 · 6289700
1 parent 1a8c378
commit 6289700
Show file tree

Hide file tree

Showing 10 changed files with 12,490 additions and 560 deletions.
diff --git a/.commitlintrc.json b/.commitlintrc.json
@@ -0,0 +1,26 @@
+{
+  "extends": ["@commitlint/config-conventional"],
+  "rules": {
+    "type-enum": [
+      2,
+      "always",
+      [
+        "build",
+        "chore",
+        "ci",
+        "docs",
+        "feat",
+        "fix",
+        "perf",
+        "refactor",
+        "revert",
+        "style",
+        "test"
+      ]
+    ],
+    "header-max-length": [2, "always", 72],
+    "body-max-line-length": [0, "always", 100],
+    "subject-full-stop": [0, "never", "."]
+  },
+  "helpUrl": "https://github.com/dialpad/dialtone/blob/staging/.github/COMMIT_CONVENTION.md"
+}
diff --git a/.github/COMMIT_CONVENTION.md b/.github/COMMIT_CONVENTION.md
@@ -0,0 +1,77 @@
+## Git Commit Message Convention
+
+Dialtone uses [Conventional Commits specification](https://www.conventionalcommits.org/en/v1.0.0/) for the commit messages in the release branches: `production`, `staging`, `alpha` and `beta`. Make sure every commit you want to include in the [semantic release process](RELEASING.md) is meeting this specification. When opening a PR, ensure the PR's title also complies with the Conventional Commits specification. This way, if your PR is merged using squash strategy, the PR's title will be used as the commit message except when your PR contains a single commit, in this case Github will use this commit for the commit message when your PR is merged, so in this case to meet the convention on the single commit of your PR is required.
+
+Consult [the rules](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional#rules) that are considered problems in the commit message.
+
+Each commit message consists of a **header**, a **body**, and a **footer**.
+
+```
+<header>
+<BLANK LINE>
+<body - optional>
+<BLANK LINE>
+<footer - optional>
+```
+
+The `header` is mandatory and has a **type**, **scope** (optional) and **subject**:
+
+```
+<type>(<scope - optional>): <subject>
+```
+
+### Type:
+
+Must be one of the following:
+
+* **build**: changes that affect the build system.
+* **chore**: general changes that don't fit in other types (code formatting, version changes).
+* **ci**: changes to the CI configuration, files and scripts.
+* **docs**: documentation changes.
+* **feat**: a new feature (corresponding with `MINOR` in SemVer).
+* **fix**: a bug fix (corresponding with `PATCH` in SemVer).
+* **perf**: performance improvements.
+* **refactor**: changes that neither fix a bug nor add a feature.
+* **revert**: changes that revert a commit.
+* **style**: not relevant changes (whitespace, code formatting, semicolons, etc).
+* **test**: changes that add or modify tests.
+
+> Only `feat`, `fix` and `perf` types trigger a new release. Commits with `BREAKING CHANGE:` in the footer of the commit message, regardless of type, will generate a `MAJOR` release.
+
+### Scope:
+
+The optional scope allows to specify the place of the change. For instance, if the commit affects a specific component, use the component's name as scope:
+
+```
+feat(select-menu): add leftIcon prop
+```
+
+### Subject:
+
+The subject contains a short description of the change:
+
+- use the imperative, present tense: "change" not "changed" nor "changes"
+- don't capitalize first letter
+- no dot (.) at the end of the sentence
+
+### Examples
+
+#### Commit message with only header
+
+```
+feat: add danger style to Modal component
+```
+
+#### Commit message with scope
+
+```
+feat(modal): add danger style
+```
+
+#### Commit message with BREAKING CHANGE footer
+
+```
+feat: remove "Mark Pro" font family
+
+BREAKING CHANGE: remove "Mark Pro" font family used in Dialtone 5.
+```
diff --git a/.github/RELEASING.md b/.github/RELEASING.md
@@ -0,0 +1,53 @@
+# Releasing
+
+## Requirements to run `semantic-release`, which is used in this guide https://semantic-release.gitbook.io/semantic-release/#requirements
+
+`semantic-release` uses the commit messages to determine the consumer impact of changes in the codebase. In dialtone-tokens we use [conventional commits specification](https://www.conventionalcommits.org/en/v1.0.0/#specification) for commit messages, so semantic-release automatically determines the next semantic version number, generates a changelog and publishes the release.
+
+| Commit Type | Release type           |
+| ------------- |:-------------:|
+| Commit with breaking change     | Major release |
+| Commit with type feat      | Minor release      |
+| Commit with type fix | Patch release      |
+| Commit with type perf | Patch release      |
+
+## Steps
+
+In order to push the `production` branch to deploy the documentation site and/or trigger a release to [npmjs](https://npmjs.com) and Github Releases, you will need to either be an admin of the dialtone-tokens repository, be a user with the "Maintain" role or have manually been given permission on your user.
+
+1. Make sure your `staging` and `production` branches are up-to-date locally. You should be in the `staging` branch. If you want to make a prerelease, it should be `beta` or `alpha` branch instead of `staging`.
+2. Stop your local server and keep your working directory clean before versioning.
+3. In your CLI window, run `npm run release` from the dialtone-tokens repository directory.
+4. If there are changes that should trigger a release:
+   - The script will update the `package.json` and `package-lock.json` files with the version number according to the types of changes introduced since the last release and will add release notes in the `CHANGELOG.MD` file.
+   - A release commit and a git tag associated with this commit will be created and pushed to the remote.
+5. If there are no relevant changes to trigger a release, you can still deploy changes to the documentation site.
+
+---
+
+**If you have made a production release:**
+
+6. We are ready to deploy the release. Switch to the `production` branch: `git checkout production`.
+7. Merge the release commits from `staging` using [`fast-forward` strategy](https://git-scm.com/docs/git-merge#Documentation/git-merge.txt---ff-only): `git merge staging --ff-only`.
+8. If the commits merged correctly, we can now push to the remote: `git push`.
+
+---
+
+**If you have made a pre-release (`alpha` or `beta`):**
+
+6. Since your pre-release branch was pushed to the remote, the deploy Github Action should have been triggered.
+7. Update the `staging` branch with the release you have made on `alpha` or `beta` branch:
+
+Replace `$BRANCH` with `alpha` or `beta` depending on the pre-release you made:
+```
+git checkout staging
+git merge --ff-only $BRANCH
+```
+8. Push to the remote: `git push`. Make sure `staging` and the release branch keep up-to-date after the release.
+
+---
+
+9. If there were changes to the library, GitHub Actions will now deploy a new release of dialtone-tokens to npm.
+11. You should be able to see your deployment running at [Dialtone Tokens Github actions](https://github.com/dialpad/dialtone-tokens/actions).
+12. When the Github Actions have been completed, the new version of the package should have been deployed to Github releases and npm.
+13. Now you’re ready to update your projects to use the latest dialtone-tokens version 🎉.
diff --git a/.github/workflows/lint-commit-message.yml b/.github/workflows/lint-commit-message.yml
@@ -0,0 +1,31 @@
+name: Lint commit message
+
+on:
+  push:
+    branches:
+      - staging
+      - production
+
+jobs:
+  commitlint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Use Node.js
+        uses: actions/setup-node@v1
+        with:
+          node-version: '16.x'
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Lint commit message
+        run: |
+          echo "This commit should adhere to the commit message convention."
+          echo "correct format: <type>(<scope>): <subject>"
+          echo "example: feat: add modal component"
+          echo "Please amend your commit message (git commit --amend) if commitlint reports an error and push using: git push --force-with-lease"
+          npx commitlint --verbose << EOF
+          ${{ github.event.head_commit.message }}
+          EOF
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
@@ -0,0 +1,49 @@
+name: Release
+
+on:
+  push:
+    branches:
+      - production
+      - alpha
+      - beta
+    paths:
+      - 'base.json'
+      - 'tokens/**/*.json'
+
+jobs:
+  release:
+    concurrency: ${{ github.workflow }}-${{ github.ref }}
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Check out branch
+        uses: actions/checkout@v3
+
+      - name: Use Node.js
+        uses: actions/setup-node@v1
+        with:
+          node-version: '16.x'
+
+      - name: parse branch from ref
+        id: branch
+        run: echo ::set-output name=BRANCH::${GITHUB_REF/refs\/heads\//}
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Set npm token
+        run: npm config set //registry.npmjs.org/:_authToken=${{ secrets.DIALTONE_NPM_TOKEN }}
+
+      # note that npm run build is executed before publishing via prepublishOnly
+      - name: Deploy production
+        if: ${{ github.ref == 'refs/heads/production' }}
+        run: npm publish
+
+      - name: Deploy prerelease
+        if: ${{ github.ref != 'refs/heads/production' }}
+        run: npm publish --tag ${{ steps.branch.outputs.BRANCH }}
+
+      - name: Github Release
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: npx semantic-release --extends ./release-ci.config.js
diff --git a/.nvmrc b/.nvmrc
@@ -0,0 +1 @@
+16