pr-title-conventional-commits

pr-title-conventional-commits action

This actions checks that the Pull Request title follows guidelines of Conventional Commits v1.0.0.

It also has the ability to post a comment in the Pull Request conversation with examples, when the Pull Request title is not compliant.

Why do I need this action?

At Bonitasoft, we mainly use "squash and merge" for Pull Requests, and we often use the Pull Request title as the basis of the merge commit (this can be suggested by GitHub by repository configuration).

We want the commits to conform to Conventional Commits, so checking the Pull Request title is very helpful.

Why developing a new action?

Having a dedicated action also helps us to change the implementation transparently for the repositories that consumes it, without having to change every repository configuration if a better action emerges.
We also need an action with convenient default values to minimize its configuration.

In the past, Bonitasoft repositories were using various public actions and the checks done by these actions were not the same. We expect more consistency with this new action. For more details about the actions previously used and their limitations, see bonita-documentation-site#422 and #82.

The pr-title-conventional-commits action uses conventional-commits-pr-action under the hood. It set other defaults and provide more features.

Usage

See action.yml for the detailed list of inputs and outputs.

Permissions

When setting the comment input to true or auto (default), set the pull-requests permission to write.

Example

on:
  pull_request_target:
    # trigger when the Pull Request title changes
    types: [opened, edited, reopened]
jobs:
  pr-title:
    runs-on: ubuntu-22.04
    permissions:
      pull-requests: write # post comments when the Pull Request title doesn't match the "Conventional Commits" rules
    steps:
      - name: Check Pull Request title
        uses: bonitasoft/actions/packages/pr-title-conventional-commits@TAGNAME

In the example above, the workflow is triggered on the pull_request_target event. This allows comments to be created even in situations where the GITHUB_TOKEN only has read permissions, such as when the Pull Request is created from a forked repository (i.e. from external contributors without push access to the repository) or by robots (like dependabot).

Using pull_request_target is valid here as the workflow doesn't generate anything from the code, it only checks the Pull Request metadata , see:

• https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/#improvements-for-public-repository-forks
• https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

In the example above, the workflow can also be triggered on the pull_request event. When the comment input is set to auto, the action won't create a comment when the Pull Request is created from a forked repository.