Lintje GitHub Action

Validate Git commits on every push with GitHub Actions. Learn more about Lintje on the Lintje.dev website.

Lintje.dev website | Lintje on GitHub marketplace

---

Table of Contents

• Overview
• Usage
  • Checkout fetch-depth
  • Tag version number
• Configuration
  • Example configuration
• Development
• Code of Conduct

Overview

Lintje is a Git linter for people to help write individuals and team write better commits. Visit the Lintje.dev website to learn more about how to use Lintje and the rules it uses to validate commits and branches.

Using this GitHub Action Lintje will automatically validate the pushed Git commit on the repository, and multiple commits if more than one was pushed.

For Pull Requests it will not validate all commits in the Pull Request. Previously pushed commits may have already failed previous builds, which will also fail the build when the branch is merged.

Usage

Create a new GitHub Actions workflow or add it to an existing workflow that already does testing and linting steps.

Add steps that uses the actions/checkout@v4 and lintje/[email protected] actions like shown below.

name: "Your workflow name"
on: [push]

jobs:
  lintje: # Add a new job for Lintje
    name: "Lintje (Git linter)"
    runs-on: ubuntu-latest # Supported on ubuntu, macOS and Microsoft Windows
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0 # Fetch depth is required
      - uses: lintje/[email protected]

Checkout fetch-depth

Configure the actions/checkout@v4 action to use fetch-depth: 0 to fetch the entire Git history of the repository. By default the checkout action only fetches the last commit, which makes it impossible for Lintje to test multiple commits if more than one commit was pushed. The fetch-depth: 0 value means the entire Git history gets fetched.

You can also choose to set it to another value that's high enough to fetch all you'll ever push, like fetch-depth: 100, if you never push more than 100 commits at a time.

Tag version number

The tag for the Lintje action v#.#.# corresponds to the Lintje release with the same version number. Upgrade Lintje in your build by updating the version number.

Configuration

Like Lintje itself, the Lintje GitHub Action has minimal configuration. The following configuration options are available.

• branch_validation (Default value: true):
  • Configure Lintje's Git branch validation. Setting this to false is the equivalent of calling lintje --no-branch. Read more about the --no-branch CLI flag.
• hints (Default value: true):
  • Configure Lintje's hints output. Hints will not fail the validation. Settings this to false is the equivalent of calling lintje --no-hints. Read more about the --no-hints CLI flag.
• color (Default value: true):
  • Configure Lintje's colorized output. Setting this to false is the equivalent of calling lintje --no-color. Read more about the --no-color CLI flag.
• verbose (Default value: false):
  • Configure Lintje's verbose mode. Setting this to true is the equivalent of calling lintje --verbose. Read more about the --verbose CLI flag.

Read more about how to configure Lintje.

Example configuration

- uses: lintje/[email protected]
  inputs:
    branch_validation: false # Turn off branch validation. On by default
    hints: false # Turn off hints. On by default

Development

To update the Lintje GitHub Action to the latest Lintje release, follow these steps:

• Update the src/version.js file to the new version number.
• Update this README.md file to use the new version number.
• Update the checksums_256.txt file with the file included in the new release.
• Update the GitHub Action to match any changed behavior or add new config options.
• Update the CHANGELOG.md file with the latest changes.
• Tag the new release in Git using the same version number: git tag v#.#.#
• Tag the new release in Git using the minor version number: git tag v#.#
• Push the updated GitHub Action branches with the multiple tags.
• Create a new release on GitHub and publish the new release to the GitHub marketplace.

Code of Conduct

This project has a Code of Conduct and contributors are expected to adhere to it.