mirror of https://github.com/pypiserver/pypiserver synced 2024-11-09 16:45:51 +01:00

chore: add GitHub container registry for stable images (#521 )

* chore: extend docs

* chore(wip): attach ghcr

* chore(test): mock a docker-build-push run

* chore(test): verify `unstable` skips GHCR

* chore(test): second mock attempt to skip GHCR

* chore: cleanup after successful tests

2023-08-30 12:29:02 +02:00

3.8 KiB

Raw Blame History

`Pypi-server` Release Workflow Reference

The official pypi-server releases are handled using GitHub Actions workflows.

General release process

flowchart LR
    rc["release-candidate ⭐️"]
    rn["release-notes 📝"]
    rm["confirmed-tag ✅"]
    ci["code-checks 🧪"]
    pk["build-and-pack 📦"]
    py["pypi-index 🗃️"]
    do["docker-hub 🐳"]
    gh["gh-container-registry 🚀"]
    gr["github-release 📣"]

    subgraph "Preparation 🌱"
    rc-->rn-->rm
    end
    subgraph "Integration 🪴"
    rm-->ci-->pk
    end
    subgraph "Deploy 🌳"
    pk--> py & do & gh & gr
    end

Process walkthrough

🗺️ This description approximates the real GitHub workflows and steps.
👀 For a more detailed view, do check out the linked resources as you read.

Preparation 🌱

🛠️ These step are applicable only for maintainers.

Release candidate ⭐️

A new release candidate can be initiated manually or on a monthly schedule.

This is done via the rc.yml GH Workflow's workflow_dispatch or schedule trigger.

The workflow automatically prepares a list of changes for the CHANGES.rst and creates a new Pull Request (rc PR) named chore(auto-release-candidate-YYY-MM-DD) including these draft change notes.

Release notes 📝

In the created rc PR, open the CHANGES.rst and:

adjust the suggested changelog items
choose & set the next released version
set the right release date

Commit the changes and push them to the head branch of the rc PR.

Confirmed tag ✅

Once everything is looking good, approve and merge the rc PR.

It will create the new commit with the updated CHANGES.rst on the default branch.
Next, to create a release tag, manually run the rt.yml GH Workflow.

First, it executes all the bumpver procedures.

Next, it commits and pushes the new version tag to the default branch.

Integration 🪴

Code checks 🧪

Once any commmit or tag is pushed to the default branch, ci.yml GH Workflow automatically executes diverse code checks: e.g. linting, formatting, tests.

Build and pack 📦

If all the checks are successful, ci.yml builds all the code artifacts: e.g. wheels, docker images.

Deploy 🌳

Publish to PyPi 🗃️

🏷️ This happens only on new version tags.

Once everythig is built, ci.yml uploads the wheels to the pypiserver PyPi project.

Publish to Docker Hub 🐳

🏷️ Docker image tags are determined on the fly.

If all is successful so far, ci.yml tags the built docker images and pushes them to the pypiserver Docker Hub repository.

Publish to GitHub Container Registry 🚀