Skip to content
Latchkey

Release workflow (chardet/chardet)

The Release workflow from chardet/chardet, explained and optimized by Latchkey.

C

CI health: C - fair

Point runs-on at Latchkey and get run de-duplication, job timeouts, SHA-pinned actions, self-healing for flaky steps, and up to 58% lower cost, applied automatically.

Grade your own workflow free or run it on Latchkey →
Source: chardet/chardet.github/workflows/release.ymlLicense 0BSDView source

What it does

This is the Release workflow from the chardet/chardet repository, a real project running GitHub Actions. It is shown here with attribution under its 0BSD license.

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

The workflow

workflow (.yml)
name: Release

on:
  push:
    tags:
      - "[0-9]+.[0-9]*"
  workflow_dispatch:

permissions:
  contents: read

jobs:
  build-sdist:
    name: Build sdist
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: astral-sh/setup-uv@v7
      - run: uv build --sdist
      - uses: actions/upload-artifact@v4
        with:
          name: dist-sdist
          path: dist/*.tar.gz

  build-pure-wheel:
    name: Build pure Python wheel
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: astral-sh/setup-uv@v7
      - run: uv build --wheel
      - uses: actions/upload-artifact@v4
        with:
          name: dist-pure-wheel
          path: dist/*.whl

  build-mypyc-wheels:
    name: Build mypyc wheels (${{ matrix.name }})
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        include:
          - { os: ubuntu-latest,      name: linux-x86_64,       cibw_archs_linux: x86_64  }
          - { os: ubuntu-24.04-arm,   name: linux-aarch64,      cibw_archs_linux: aarch64 }
          # riscv64 is split per Python version so each gets its own RISE
          # runner and they build in parallel (~3 min each vs ~15 min serial).
          - { os: ubuntu-24.04-riscv, name: linux-riscv64-310,  cibw_archs_linux: riscv64, cibw_build: "cp310-*" }
          - { os: ubuntu-24.04-riscv, name: linux-riscv64-311,  cibw_archs_linux: riscv64, cibw_build: "cp311-*" }
          - { os: ubuntu-24.04-riscv, name: linux-riscv64-312,  cibw_archs_linux: riscv64, cibw_build: "cp312-*" }
          - { os: ubuntu-24.04-riscv, name: linux-riscv64-313,  cibw_archs_linux: riscv64, cibw_build: "cp313-*" }
          - { os: ubuntu-24.04-riscv, name: linux-riscv64-314,  cibw_archs_linux: riscv64, cibw_build: "cp314-*" }
          - { os: macos-latest,       name: macos,              cibw_archs_linux: auto    }
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: astral-sh/setup-uv@v7
      # The pypa/cibuildwheel action internally calls actions/setup-python,
      # which has no riscv64 binaries. On native riscv64 runners, invoke
      # cibuildwheel directly with the system Python instead.
      - if: "!startsWith(matrix.name, 'linux-riscv64')"
        uses: pypa/cibuildwheel@v3.3
        env:
          CIBW_ARCHS_LINUX: ${{ matrix.cibw_archs_linux }}
          CIBW_BUILD: ${{ matrix.cibw_build || '*' }}
          CIBW_ENVIRONMENT_PASS_LINUX: HATCH_BUILD_HOOK_ENABLE_MYPYC
          HATCH_BUILD_HOOK_ENABLE_MYPYC: "true"
      - if: startsWith(matrix.name, 'linux-riscv64')
        run: |
          python3 -m pip install cibuildwheel
          python3 -m cibuildwheel --output-dir wheelhouse
        env:
          CIBW_ARCHS_LINUX: riscv64
          CIBW_BUILD: ${{ matrix.cibw_build }}
          CIBW_ENVIRONMENT_PASS_LINUX: HATCH_BUILD_HOOK_ENABLE_MYPYC
          HATCH_BUILD_HOOK_ENABLE_MYPYC: "true"
      - uses: actions/upload-artifact@v4
        with:
          name: dist-mypyc-${{ matrix.name }}
          path: wheelhouse/*.whl

  build-mypyc-wheels-windows:
    name: Build mypyc wheels (windows-latest)
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      # MSVC has a 16,380-char string literal limit (C2026). mypyc generates
      # a single C file with an encoded source map that exceeds this with 11
      # modules. Use separate=true on Windows so each module gets its own
      # extension, avoiding the limit. This is ~50% slower than the
      # single-library build used on Linux/macOS.
      - name: Patch pyproject.toml for MSVC compatibility
        run: |
          (Get-Content pyproject.toml) -replace 'options = \{ debug_level = "0" \}', 'options = { debug_level = "0", separate = true }' | Set-Content pyproject.toml
        shell: pwsh
      # Hide the patch from git so hatch-vcs derives the clean tagged version
      # instead of a dirty dev version (e.g. 7.4.0.post2.dev0+g...).
      - name: Restore clean git state for version derivation
        run: git update-index --assume-unchanged pyproject.toml
      - uses: astral-sh/setup-uv@v7
      - uses: pypa/cibuildwheel@v3.3
        env:
          HATCH_BUILD_HOOK_ENABLE_MYPYC: "true"
      - uses: actions/upload-artifact@v4
        with:
          name: dist-mypyc-windows-latest
          path: wheelhouse/*.whl

  publish:
    name: Publish to PyPI
    needs: [build-sdist, build-pure-wheel, build-mypyc-wheels, build-mypyc-wheels-windows]
    runs-on: ubuntu-latest
    environment: pypi
    permissions:
      id-token: write
    steps:
      - uses: actions/download-artifact@v4
        with:
          pattern: dist-*
          path: dist
          merge-multiple: true
      - uses: pypa/gh-action-pypi-publish@release/v1
        with:
          skip-existing: true

The same workflow, on Latchkey

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

name: Release
 
on:
  push:
    tags:
      - "[0-9]+.[0-9]*"
  workflow_dispatch:
 
permissions:
  contents: read
 
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
 
jobs:
  build-sdist:
    timeout-minutes: 30
    name: Build sdist
    runs-on: latchkey-small
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: astral-sh/setup-uv@v7
      - run: uv build --sdist
      - uses: actions/upload-artifact@v4
        with:
          name: dist-sdist
          path: dist/*.tar.gz
 
  build-pure-wheel:
    timeout-minutes: 30
    name: Build pure Python wheel
    runs-on: latchkey-small
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: astral-sh/setup-uv@v7
      - run: uv build --wheel
      - uses: actions/upload-artifact@v4
        with:
          name: dist-pure-wheel
          path: dist/*.whl
 
  build-mypyc-wheels:
    timeout-minutes: 30
    name: Build mypyc wheels (${{ matrix.name }})
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        include:
          - { os: ubuntu-latest,      name: linux-x86_64,       cibw_archs_linux: x86_64  }
          - { os: ubuntu-24.04-arm,   name: linux-aarch64,      cibw_archs_linux: aarch64 }
          # riscv64 is split per Python version so each gets its own RISE
          # runner and they build in parallel (~3 min each vs ~15 min serial).
          - { os: ubuntu-24.04-riscv, name: linux-riscv64-310,  cibw_archs_linux: riscv64, cibw_build: "cp310-*" }
          - { os: ubuntu-24.04-riscv, name: linux-riscv64-311,  cibw_archs_linux: riscv64, cibw_build: "cp311-*" }
          - { os: ubuntu-24.04-riscv, name: linux-riscv64-312,  cibw_archs_linux: riscv64, cibw_build: "cp312-*" }
          - { os: ubuntu-24.04-riscv, name: linux-riscv64-313,  cibw_archs_linux: riscv64, cibw_build: "cp313-*" }
          - { os: ubuntu-24.04-riscv, name: linux-riscv64-314,  cibw_archs_linux: riscv64, cibw_build: "cp314-*" }
          - { os: macos-latest,       name: macos,              cibw_archs_linux: auto    }
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: astral-sh/setup-uv@v7
      # The pypa/cibuildwheel action internally calls actions/setup-python,
      # which has no riscv64 binaries. On native riscv64 runners, invoke
      # cibuildwheel directly with the system Python instead.
      - if: "!startsWith(matrix.name, 'linux-riscv64')"
        uses: pypa/cibuildwheel@v3.3
        env:
          CIBW_ARCHS_LINUX: ${{ matrix.cibw_archs_linux }}
          CIBW_BUILD: ${{ matrix.cibw_build || '*' }}
          CIBW_ENVIRONMENT_PASS_LINUX: HATCH_BUILD_HOOK_ENABLE_MYPYC
          HATCH_BUILD_HOOK_ENABLE_MYPYC: "true"
      - if: startsWith(matrix.name, 'linux-riscv64')
        run: |
          python3 -m pip install cibuildwheel
          python3 -m cibuildwheel --output-dir wheelhouse
        env:
          CIBW_ARCHS_LINUX: riscv64
          CIBW_BUILD: ${{ matrix.cibw_build }}
          CIBW_ENVIRONMENT_PASS_LINUX: HATCH_BUILD_HOOK_ENABLE_MYPYC
          HATCH_BUILD_HOOK_ENABLE_MYPYC: "true"
      - uses: actions/upload-artifact@v4
        with:
          name: dist-mypyc-${{ matrix.name }}
          path: wheelhouse/*.whl
 
  build-mypyc-wheels-windows:
    timeout-minutes: 30
    name: Build mypyc wheels (windows-latest)
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      # MSVC has a 16,380-char string literal limit (C2026). mypyc generates
      # a single C file with an encoded source map that exceeds this with 11
      # modules. Use separate=true on Windows so each module gets its own
      # extension, avoiding the limit. This is ~50% slower than the
      # single-library build used on Linux/macOS.
      - name: Patch pyproject.toml for MSVC compatibility
        run: |
          (Get-Content pyproject.toml) -replace 'options = \{ debug_level = "0" \}', 'options = { debug_level = "0", separate = true }' | Set-Content pyproject.toml
        shell: pwsh
      # Hide the patch from git so hatch-vcs derives the clean tagged version
      # instead of a dirty dev version (e.g. 7.4.0.post2.dev0+g...).
      - name: Restore clean git state for version derivation
        run: git update-index --assume-unchanged pyproject.toml
      - uses: astral-sh/setup-uv@v7
      - uses: pypa/cibuildwheel@v3.3
        env:
          HATCH_BUILD_HOOK_ENABLE_MYPYC: "true"
      - uses: actions/upload-artifact@v4
        with:
          name: dist-mypyc-windows-latest
          path: wheelhouse/*.whl
 
  publish:
    timeout-minutes: 30
    name: Publish to PyPI
    needs: [build-sdist, build-pure-wheel, build-mypyc-wheels, build-mypyc-wheels-windows]
    runs-on: latchkey-small
    environment: pypi
    permissions:
      id-token: write
    steps:
      - uses: actions/download-artifact@v4
        with:
          pattern: dist-*
          path: dist
          merge-multiple: true
      - uses: pypa/gh-action-pypi-publish@release/v1
        with:
          skip-existing: true
 

What changed

3 third-party actions are referenced by a movable tag. Pin them to the commit SHA (Latchkey resolves and applies this automatically) so a repointed tag cannot change what runs.

What Latchkey heals here

This workflow has steps that commonly fail on transient issues (network, registries, flaky browsers). On Latchkey managed runners they are detected, retried, and self-healed instead of failing your build:

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

Actions used in this workflow