A comprehensive GitHub Action for Python code quality enforcement. Runs Pylint, Black, and MyPy with automatic badge generation and detailed reporting.
- π Flexible Python version support - Specify any Python version using
actions/setup-python - π¦ Custom requirements - Install additional dependencies from a requirements file
- π Comprehensive linting - Run Pylint, Black, and MyPy in a single action
- π Detailed reporting - View results in GitHub Actions summary
- π Automatic badge generation - Creates and commits SVG badges for each linter
- βοΈ Highly configurable - Customize options for each linting tool
- Your repository must contain Python code
- For badge commits: the workflow needs
contents: writepermission
name: Python Linting
on: [push, pull_request]
jobs:
lint:
runs-on: ubuntu-latest
permissions:
contents: write # Required for badge commits
steps:
- uses: actions/checkout@v4
- name: Python Linting
uses: thoughtparametersllc/python-linting@v1name: Python Linting
on: [push, pull_request]
jobs:
lint:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v4
- name: Python Linting
uses: thoughtparametersllc/python-linting@v1
with:
python-version: '3.11'
requirements-file: 'requirements.txt'
pylint-options: '--max-line-length=120 --disable=C0111'
black-options: '--line-length=120'
mypy-options: '--strict --ignore-missing-imports'
commit-badges: 'true'
badge-directory: '.github/badges'- name: Python Linting
uses: thoughtparametersllc/python-linting@v1
with:
python-version: '3.10' # Always quote version numbers
commit-badges: 'false' # Disable automatic badge commitsname: Python Linting
on: [push, pull_request]
jobs:
lint:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ['3.9', '3.10', '3.11', '3.12']
steps:
- uses: actions/checkout@v4
- name: Python Linting
uses: thoughtparametersllc/python-linting@v1
with:
python-version: ${{ matrix.python-version }}
commit-badges: ${{ matrix.python-version == '3.11' && 'true' || 'false' }} # Only the Python 3.11 job commits badges| Input | Description | Required | Default |
|---|---|---|---|
python-version |
Python version to use for linting | No | 3.x |
requirements-file |
Path to requirements file for additional dependencies | No | requirements.txt |
pylint-options |
Additional options to pass to pylint | No | '' |
black-options |
Additional options to pass to black | No | '' |
mypy-options |
Additional options to pass to mypy | No | '' |
commit-badges |
Whether to commit generated SVG badges back to the repository | No | true |
badge-directory |
Directory to save the generated SVG badges | No | .github/badges |
This action does not produce any outputs. Results are displayed in the GitHub Actions summary and as SVG badges (if enabled).
When commit-badges is set to true (default), the action automatically generates and commits three SVG badge files to your repository:
{badge-directory}/pylint.svg- Pylint status badge{badge-directory}/black.svg- Black status badge{badge-directory}/mypy.svg- MyPy status badge
Add these badges to your README.md to show linting status:


- π’ Green (
success) - No issues found - π΄ Red (
failure) - Issues detected
This action requires the following permissions:
permissions:
contents: write # Required only if commit-badges is 'true'If you set commit-badges: 'false', you can use:
permissions:
contents: readIssue: The action fails to commit badges back to the repository.
Solutions:
- Ensure
contents: writepermission is set in your workflow - Verify that branch protection rules allow the
github-actions[bot]to push - Check that the badge directory exists or can be created
Issue: Pylint, Black, or MyPy commands fail with "command not found".
Solutions:
- Ensure Python is properly set up (the action handles this automatically)
- Check that the Python version you specified is available
- Review the "Install Linting Tools" step logs for errors
Issue: Additional requirements cannot be installed.
Solutions:
- Verify the
requirements-filepath is correct relative to repository root - Ensure the requirements file exists and is readable
- Check for syntax errors in the requirements file
- Review dependency conflicts in the workflow logs
Issue: Linters report issues that you want to ignore.
Solutions:
- Use linter-specific options to customize behavior:
- Pylint:
pylint-options: '--disable=C0111,W0212' - Black:
black-options: '--line-length=120' - MyPy:
mypy-options: '--ignore-missing-imports'
- Pylint:
- Create configuration files (
.pylintrc,pyproject.toml) in your repository
Issue: Badge commits fail on pull requests from forked repositories.
Solution: This is expected behavior for security reasons. Forks don't have write access. Consider:
- Setting
commit-badges: 'false'for PRs from forks - Using a conditional in your workflow:
commit-badges: ${{ github.event.pull_request.head.repo.full_name == github.repository && 'true' || 'false' }}
- Setup Python: Installs specified Python version
- Install Tools: Installs Pylint, Black, and MyPy
- Install Requirements: (Optional) Installs dependencies from your requirements file
- Run Linters: Executes all three linting tools sequentially
- Generate Badges: Creates SVG badges showing pass/fail status
- Commit Badges: (Optional) Commits badges back to your repository
- Generate Summary: Creates detailed GitHub Actions summary with results
β Good use cases:
- CI/CD pipelines for Python projects
- Pre-merge checks on pull requests
- Automated code quality enforcement
- Ensuring consistent code style across teams
β Not recommended for:
- Local development (use pre-commit hooks instead)
- Projects with custom linting workflows requiring specific tool versions
- Repositories with complex multi-language setups
name: Code Quality
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
lint:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v4
- name: Python Linting
uses: thoughtparametersllc/python-linting@v1
with:
python-version: '3.11'
requirements-file: 'requirements.txt'You can customize linter behavior using configuration files in your repository:
- Pylint:
.pylintrcorpyproject.toml - Black:
pyproject.toml - MyPy:
mypy.iniorpyproject.toml
Example pyproject.toml:
[tool.black]
line-length = 120
target-version = ['py311']
[tool.mypy]
python_version = "3.11"
warn_return_any = true
warn_unused_configs = true
[tool.pylint.format]
max-line-length = 120
[tool.pylint.messages_control]
disable = ["C0111", "C0103"]name: Test and Lint
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with:
python-version: '3.11'
- run: pip install -r requirements.txt
- run: pytest
lint:
runs-on: ubuntu-latest
needs: test # Run after tests pass
permissions:
contents: write
steps:
- uses: actions/checkout@v4
- uses: thoughtparametersllc/python-linting@v1
with:
requirements-file: 'requirements.txt'name: Lint Python Code
on: [push]
jobs:
lint:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v4
# Note: The action runs from repository root regardless of working-directory settings
# Specify full paths from root for requirements-file and Python code location
- name: Python Linting
uses: thoughtparametersllc/python-linting@v1
with:
requirements-file: './python-service/requirements.txt'name: PR Linting Check
on: pull_request
jobs:
lint:
runs-on: ubuntu-latest
permissions:
contents: read # Read-only for PR checks
steps:
- uses: actions/checkout@v4
- name: Python Linting
uses: thoughtparametersllc/python-linting@v1
with:
commit-badges: 'false'This repository includes comprehensive GitHub workflows for CI/CD:
- Test Action: Validates all action features across multiple Python versions
- Lint & Test: Ensures code quality with Pylint, Black, MyPy, and Flake8
- Changelog Check: Requires changelog updates for substantive changes
- Release & Marketplace: Automated semantic versioning and tagging
For detailed workflow documentation, see .github/WORKFLOWS.md.
See .github/WORKFLOW_QUICK_START.md for a quick reference guide.
The release workflow supports both automatic semantic versioning and manual version specification:
Automatic Release (when changes are merged to main):
- Automatically detects version bump from CHANGELOG.md
- Creates release with extracted changelog notes
- Updates major version tag (e.g., v1)
Manual Release (for specific versions):
- Go to Actions β Release and Marketplace β Run workflow
- Enter version as
1.0.0orv1.0.0(for specific version) ormajor/minor/patch(for semantic bump) - The workflow will create the release and update tags
We welcome contributions! Please see CONTRIBUTING.md for detailed guidelines.
Quick steps:
- Fork the repository
- Create a feature branch
- Make your changes
- Update CHANGELOG.md under the
[Unreleased]section - Ensure all tests pass
- Submit a pull request
- π Documentation
- π Report a Bug
- π‘ Request a Feature
- π Security Policy
This project is licensed under the MIT License - see the LICENSE file for details.
Built with: