Port mailsuite's tag-triggered release pipeline:
- Add release.yml: pushing a version tag runs the full CI suite
(python-tests.yml via workflow_call), then builds the package (the tag
must match the version in parsedmarc/constants.py, checked with
`hatch version`), publishes to PyPI via Trusted Publishing, creates
the GitHub Release with notes from the tag's CHANGELOG.md section and
the built distributions attached, pushes the multi-arch Docker image,
and deploys the Sphinx docs
- Add docs.yml: reusable docs build/deploy to GitHub Pages, also
runnable on demand (workflow_dispatch) for documentation-only changes
between releases
- docker.yml: add a workflow_call trigger with a push_image input, since
a GitHub Release created with the workflow's own GITHUB_TOKEN emits no
`release: published` event; release.yml calls it directly instead
- Remove the legacy build.sh / publish-docs.sh manual process
- AGENTS.md: CRITICAL rule that releases require explicit maintainer
permission, plus docs for the new release flow and its one-time
repo/PyPI configuration prerequisites
- Bump the mailsuite floor to >=2.3.0 (raises the transitive mail-parser
floor to >=4.6.2 and cryptography to >=50.0.0)
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Build multi-arch Docker images with PostgreSQL support
The prebuilt image now installs the `[postgresql]` extra, so the optional
PostgreSQL output backend (psycopg) works out of the box in the container
without a separate `pip install` (#792). The wheel path is resolved into a
variable before appending the extra so the shell doesn't treat
`*.whl[postgresql]` as a bracket glob.
The build workflow now sets up QEMU + Buildx and builds a multi-arch
manifest for `linux/amd64` and `linux/arm64`, so the image runs natively on
64-bit ARM hosts such as a Raspberry Pi (#789). Every compiled dependency
(psycopg[binary], lxml, maxminddb, cryptography) ships prebuilt aarch64
manylinux wheels, so the arm64 build adds no source-compilation step.
A `pull_request` trigger (scoped to the build inputs) and `workflow_dispatch`
are added so the multi-arch build can be validated on PRs and rebuilt on
demand; pushes are still gated on the release event, so neither pushes images.
Closes#789Closes#792
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Bump version to 10.0.4 to publish the new images
The docker workflow only pushes to the registry on a `release` event, so
shipping the multi-arch + PostgreSQL-enabled image requires cutting a
release. 10.0.3 is already tagged, so bump to 10.0.4 and document the
Docker changes in the changelog.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Don't run the docker build on pull requests
The pull_request trigger (added to validate the multi-arch build) re-ran the
full ~10-minute amd64+arm64 build on every commit pushed to a docker-touching
PR, because the pull_request `paths` filter matches against the PR's entire
diff, not just the newest commit. That is wasteful once the build has been
validated.
Drop the pull_request trigger and rely on workflow_dispatch for on-demand
validation (plus the existing master-push and release triggers). Also gate the
registry login on the release event so that no non-release run authenticates
to ghcr at all — a build can only ever be pushed from a published release.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* add dockerfile and actions task to build image
* test on branch
* change to push only on release, update readme
* remove pip install requirements
* change to on release github action
William DesportesandGitHub
Nathan ThorpeandGitHub