Reusable CI/CD components for GitHub Actions — composite actions, reusable workflows, and shell utilities.

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4

      - uses: lgtm-hq/lgtm-ci/.github/actions/setup-env@v1
        with:
          python-version: "3.13"
          node-version: "22"

jobs:
  quality:
    permissions:
      contents: read
      packages: read # pull ghcr.io/lgtm-hq/py-lintro in reusable-quality-lint
    uses: lgtm-hq/lgtm-ci/.github/workflows/reusable-quality-lint.yml@v1

  publish-quality-summary:
    needs: quality
    if: >-
      !cancelled()
      && github.event_name == 'pull_request'
      && github.event.pull_request.head.repo.fork == false
    permissions:
      contents: read
      pull-requests: write
    uses: lgtm-hq/lgtm-ci/.github/workflows/reusable-publish-quality-summary.yml@v1
    with:
      exit-code: ${{ needs.quality.outputs.exit-code }}

Reusable workflows share a standard contract (tooling-ref, egress-policy, job-name, permissions by mode). See docs/workflow-contract.md.

You do not need to copy .github/actions/harden-runner or resolve-egress-allowlist into your repository — reusables fetch them from lgtm-ci via .lgtm-ci-tooling (see docs/reusable-workflows.md and examples/README.md).

steps:
  - uses: actions/checkout@v4
    with:
      repository: lgtm-hq/lgtm-ci
      path: .lgtm-ci
      sparse-checkout: scripts/ci/lib

  - name: Use utilities
    run: |
      source .lgtm-ci/scripts/ci/lib/log.sh
      log_info "Starting build..."

Test workflows are self-contained for consumers: they check out lgtm-ci tooling internally, run the configured test suite, and post/update the standard summary comment when callers grant pull-requests: write.

Located in scripts/ci/lib/:

lgtm-ci uses semantic versioning with conventional commits for automated releases.

Releases are automated and PR-gated. Pushes to main with releasable commits (feat:, fix:, etc.) trigger a release PR for human review; merging that PR creates the tagged release and updates the floating major version tag. See Two-stage release model below for how the two workflows fit together.

Release automation is split across two reusable workflows that work together:

1. reusable-release-version-pr.yml — Runs on pushes to main. When releasable commits land, it opens (or updates) a release PR that bumps version files and updates CHANGELOG.md. This PR is the human-review gate before a release happens.
2. reusable-release-auto-tag.yml — Runs after the release PR merges (it triggers on CHANGELOG.md changes). It extracts the version from the release commit, creates an annotated tag, publishes a GitHub release, and updates the floating major version tag.

push to main
  ↓
version-pr workflow → opens "chore(release): version X.Y.Z" PR
  ↓
PR merged
  ↓
auto-tag workflow → creates tag + GitHub release

Consumers typically wire up both workflows. The version-pr caller runs on every push; the auto-tag caller runs only on pushes that touch CHANGELOG.md (i.e., the release PR merge). See .github/workflows/release-version-pr.yml and .github/workflows/release-auto-tag.yml for working examples.

CI and reusable-quality-lint.yml run lintro inside the pinned ghcr.io/lgtm-hq/py-lintro image so every bundled tool is available. Mirror CI locally:

export STEP=check
export LINTRO_IMAGE='ghcr.io/lgtm-hq/py-lintro@sha256:1ff3db35939283734b859c7c5d95be87fd8fd62734b3434e0437769d50d53578'
bash scripts/ci/quality/run-lintro-docker.sh

Quick iteration without Docker (optional tools may SKIP — same as lint-check.sh):

git clone https://github.com/lgtm-hq/lgtm-ci.git
cd lgtm-ci
uv sync --dev
STEP=check bash scripts/ci/quality/lint-check.sh

• 🐛 Bug Reports
• 💡 Feature Requests

MIT License - see LICENSE for details.