PR Conventional Commit Validation workflow (developmentseed/lonboard)

The PR Conventional Commit Validation workflow from developmentseed/lonboard, explained and optimized by Latchkey.

What it does

This is the PR Conventional Commit Validation workflow from the developmentseed/lonboard repository, a real project running GitHub Actions. It is shown here with attribution under its MIT license.

Below, Latchkey shows a faster, safer version produced by its optimization engine.

The workflow

name: PR Conventional Commit Validation

on:
  pull_request_target:
    types: [opened, synchronize, reopened, edited]

jobs:
  validate-pr-title:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/create-github-app-token@v3.2.0
        id: app-token
        with:
          app-id: ${{ secrets.DS_RELEASE_BOT_ID }}
          private-key: ${{ secrets.DS_RELEASE_BOT_PRIVATE_KEY }}
          permission-pull-requests: write

      - name: PR Conventional Commit Validation
        uses: ytanikin/pr-conventional-commits@1.5.2
        with:
          task_types: '["feat","fix","docs","test","ci","refactor","perf","chore","revert"]'
          token: ${{ steps.app-token.outputs.token }}

The same workflow, on Latchkey

Removes redundant runs and caps runaway jobs. Added and changed lines are highlighted.

name: PR Conventional Commit Validation
 
on:
  pull_request_target:
    types: [opened, synchronize, reopened, edited]
 
jobs:
  validate-pr-title:
    timeout-minutes: 30
    runs-on: latchkey-small
    steps:
      - uses: actions/create-github-app-token@v3.2.0
        id: app-token
        with:
          app-id: ${{ secrets.DS_RELEASE_BOT_ID }}
          private-key: ${{ secrets.DS_RELEASE_BOT_PRIVATE_KEY }}
          permission-pull-requests: write
 
      - name: PR Conventional Commit Validation
        uses: ytanikin/pr-conventional-commits@1.5.2
        with:
          task_types: '["feat","fix","docs","test","ci","refactor","perf","chore","revert"]'
          token: ${{ steps.app-token.outputs.token }}
 

What changed

• Run on Latchkey managed runners with one line (runs-on), which apply the fixes below automatically and self-heal transient failures. This example uses latchkey-small; pick the runner size that fits the job.
• Add a job timeout so a hung step cannot burn hours of runner time.

1 third-party action is referenced by a movable tag. Pin it to the commit SHA (Latchkey resolves and applies this automatically) so a repointed tag cannot change what runs.

This workflow runs 1 job per trigger. On Latchkey the same minutes cost up to 58% less than GitHub-hosted, with zero queue time.

Actions used in this workflow