A GitHub Action to ensure that your PR title matches a given regex.
Create a workflow definition at .github/workflows/<my-workflow>.yml
with
something like the following contents:
name: PR Lint
on:
pull_request:
# By default, a workflow only runs when a pull_request's activity type is opened, synchronize, or reopened. We
# explicity override here so that PR titles are re-linted when the PR text content is edited.
#
# Possible values: https://help.github.com/en/actions/reference/events-that-trigger-workflows#pull-request-event-pull_request
types: [opened, edited, reopened]
jobs:
pr-lint:
runs-on: ubuntu-latest
steps:
- uses: morrisoncole/pr-lint-action@v1.4.1
with:
title-regex: "#[eE][xX]-[0-9]+"
on-failed-regex-fail-action: false
on-failed-regex-request-changes: false
on-failed-regex-create-review: true
on-failed-regex-comment:
"This is just an example. Failed regex: `%regex%`!"
repo-token: "${{ secrets.GITHUB_TOKEN }}"
- Fixes #145 (thanks @jnewland! 🤩).
- Adds #119 (thanks
@bryantbiggs! 🙏) the ability to configure whether changes are requested or
not with
on-failed-regex-request-changes
. Existing behaviour is preserved. - Upgrades all dependencies.
- Adds #111, the
ability to specify whether to create a review and whether to fail the action
on a regex mismatch independently with
on-failed-regex-fail-action
&on-failed-regex-create-review
. on-failed-regex-comment
is no longer a required input.
Note: existing behaviour from previous releases is preserved without additional configuration 🙏.
Internal refactoring only:
- Upgrade dependencies.
- Move from
lib
todist
. - Address ESLint warnings.
- Fixes #92.
- Fixes #90.
Internal refactoring only:
- Upgrade dependencies.
- Configure ESLint & Prettier.
- Replaced status checks with an automatic bot review. If the PR title fails to match the regex, the bot will request changes. Once the title is edited to match it, the bot will dismiss its review.
- Upgrade dependencies.
- Initial release. This version uses action status checks but suffers from #5 since the GitHub actions API treats different hook types as separate checks by default.
Since actions are currently not grouped together, previously failed status checks were persisted despite newer runs succeeding (reported in #5). We made the decision to use a bot-based 'request changes' workflow for the time being.
yarn install
yarn build
Building outputs to dist/main.js
.