JARVIS

Appearance

Releases ​

Release Trigger ​

JARVIS uses a dedicated GitHub Actions workflow at .github/workflows/release.yml.

Releases are triggered by:

  • pushing a tag that matches v*
  • manually running the workflow with a required tag input that points to an existing tag

How To Cut A Release ​

  1. Make sure main contains the state you want to release.
  2. Create an annotated version tag.
  3. Push the tag to GitHub.

Example:

bash
git checkout main
git pull --ff-only
git tag -a v0.1.0 -m "Release v0.1.0"
git push origin v0.1.0

If the tag already exists and you want to publish from it manually, run the Release workflow from GitHub Actions and pass the same tag, for example v0.1.0.

What The Workflow Does ​

The release workflow stays focused on packaging and publishing:

  1. Checks out the tagged ref.
  2. Sets up Python 3.12.
  3. Installs the project with development dependencies plus build.
  4. Runs pytest -q.
  5. Builds Python distribution artifacts with python -m build.
  6. Creates source archives for Unix-like and Windows users.
  7. Generates checksums.txt with SHA256 hashes for every published file.
  8. Publishes all artifacts to a GitHub Release with autogenerated release notes.

Published Artifacts ​

Each release publishes:

  • jarvis-<version>.tar.gz as the Python source distribution
  • jarvis-<version>-py3-none-any.whl as the universal wheel
  • jarvis-v<version>-source.tar.gz as the Unix-like source archive
  • jarvis-v<version>-source.zip as the Windows-friendly source archive
  • checksums.txt with SHA256 hashes for all release files

The workflow uses the Git tag as the release version. For example, tag v0.1.0 produces a release named v0.1.0, and the Python package build is versioned as 0.1.0 during the workflow.

Verify Checksums ​

After downloading release files, verify them with:

bash
sha256sum -c checksums.txt

To verify a single file manually:

bash
sha256sum jarvis-v0.1.0-source.tar.gz