Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 0 additions & 29 deletions .github/workflows/python-publish.yml

This file was deleted.

69 changes: 69 additions & 0 deletions .github/workflows/release.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
name: Release

# py-canon's reusable-release, as calibre/simcheck/covered/preen use, replacing
# a bespoke `python-publish.yml`.
#
# **The PyPI trusted publisher for this project must be updated to name
# `release.yml`.** OIDC claims reference the workflow path, so publishing fails
# until that is changed on PyPI.
#
# Tests are not re-run here, by design: canon relies on CI having already run
# against the commit the tag points at.

on:
push:
tags: ["v*"]
workflow_dispatch:
inputs:
publish:
description: >-
Upload to PyPI. Only takes effect when the run is started from a tag;
from a branch this is a build-and-check rehearsal.
type: boolean
default: false

permissions:
contents: read

# A manual run and a tag push can otherwise race for the same ref: two builds,
# and two `dist` artifacts uploaded under one name.
concurrency:
group: release-${{ github.ref }}
cancel-in-progress: false

jobs:
release:
uses: gojiplus/py-canon/.github/workflows/reusable-release.yml@v1

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Configure tag-derived versions before publishing

When the release tag differs from v0.2.0, this workflow still builds package version 0.2.0: pyproject.toml declares a static version and src/streamcal/__init__.py hard-codes the same value, with no VCS-based version configuration. For example, a v0.3.0 push would create a GitHub release containing streamcal-0.2.0, and PyPI would reject that distribution if 0.2.0 is already published; configure dynamic tag-derived versioning or require and validate a matching static version before release.

Useful? React with 👍 / 👎.

permissions:
contents: write
id-token: write
with:
# `gh release create` fails when the release already exists, so create it
# only on the original tag push — not on a manual re-run of a released tag.
github-release: ${{ github.event_name == 'push' }}

# PyPI trusted publishing rejects reusable workflows (the OIDC claims
# must reference this repo's workflow file), so the publish step lives
# here rather than in py-canon's reusable-release.
publish:
needs: release
# The version is derived from the tag, so anything built off a branch is a dev
# version (1.0.post3.dev0+abc1234). A PyPI upload cannot be withdrawn, so never
# publish a non-tag build, and make a manual run opt in explicitly.
if: >-
startsWith(github.ref, 'refs/tags/') &&
(github.event_name == 'push' || inputs.publish)
runs-on: ubuntu-latest
timeout-minutes: 15
environment: pypi
permissions:
id-token: write
steps:
- uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
with:
name: dist
path: dist/
- name: Publish (trusted publishing, PEP 740 attestations)
uses: pypa/gh-action-pypi-publish@dc37677b2e1c63e2034f94d8a5b11f265b73ba33 # release/v1
with:
attestations: true