Molt

    GitLab, Gitea & others

    Molt releases from any CI, on any host. A native forge backend is what adds host-specific behavior on top of that: the release change-request, host releases, and rich author attribution. GitHub is the backend molt ships.

    Releasing without a native backend

    The core loop is host-independent. molt version, molt publish, and molt git-tag read your repository, write your manifests and changelogs, upload to PyPI, and push tags. None of that calls a code host. It runs anywhere uv is installed: GitLab CI, Gitea Actions, Jenkins, Buildkite, a cron job, or your laptop.

    uv tool install molt-release
molt version
git commit -am "Release"
molt publish

    What you write yourself on a host without a backend is the release change-request step: opening or updating the merge request that carries the version commit. That is a few lines of your host's own CLI around molt version, and CI: GitHub Action shows the portable shape.

    What a native backend adds

    A backend implements the host-agnostic contract from the forges overview:

    Question the backend answersWhat it enables
    Which change request introduced this commit, and who wrote it?Thanks @author! lines and pull-request links in changelogs
    Create a release from a tag and a changelog bodyOne host release per released package
    Find or open the release change request for a branchThe "Version Packages" merge request, kept in sync
    Commit a set of files onto a branch through the host APICommits the host signs, without a signing key in CI

    GitLab merge requests, Gitea and Bitbucket pull requests, and Azure DevOps pull requests all fit this shape. The generic caching, retry, and backoff behavior from the overview lives in the shared client, so a backend inherits it rather than reimplementing it.

    See also