add gh workflow to build/release package

Author: jkeifer

.github/workflows/python-publish.yml

@@ -0,0 +1,37 @@
+name: Build Python Package
+
+on:
+  push:
+    branches:
+      - main
+  pull_request:
+    branches:
+      - main
+  release:
+    types:
+      - published
+
+jobs:
+  build-package:
+    runs-on: ubuntu-latest
+    environment:
+      name: pypi
+      url: https://pypi.org/p/stapi-fastapi
+    permissions:
+      id-token: write
+    steps:
+      - uses: actions/checkout@v4
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.x"
+      - name: Install dependencies
+        run: |
+          python -m pip install --upgrade pip
+          pip install build
+          pip install .
+      - name: Build package
+        run: python -m build
+      - name: Publish package distributions to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1
+        if: startsWith(github.ref, 'refs/tags')

CHANGELOG.md

@@ -0,0 +1,15 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/)
+and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.html).
+
+## [Unreleased]
+
+## [v0.1.0] - 2024-10-23
+
+Initial release
+
+[unreleased]: https://github.com/stapi-spec/stapi-fastapi/compare/v0.1.0...main
+[v0.1.0]: https://github.com/stapi-spec/stapi-fastapi/tree/v0.1.0

RELEASE.md

@@ -0,0 +1,28 @@
+# Releasing stapi-fastapi
+
+Publishing a stapi-fastapi package build to PyPI is triggered by publishing a
+GitHub release. Tags are the [semantic version number](https://semver.org/)
+proceeded by a `v`, such as `v0.0.1`.
+
+Release notes for the changes for each release should be tracked in
+[CHANGELOG.md](./CHANGELOG.md). The notes for each release in GitHub should
+generally match those in the CHANGELOG.
+
+## Release process
+
+1. Prepare the release.
+   1. Figure out the next release version (following semantic versioning
+      conventions).
+   1. Ensure [CHANGELOG.md](./CHANGELOG.md) has all necessary changes and
+      release notes under this next release version. Typically this step is
+      simply a matter of adding the header for the next version below
+      `Unreleased` then reviewing the list of changes therein.
+   1. Ensure links are tracked as best as possible to relevant commits and/or
+      PRs.
+1. Make a PR with the release prep changes, get it reviewed, and merge.
+1. Draft a new GitHub release.
+   1. Create a new tag with the release version prefixed with the character `v`.
+   1. Title the release the same name as the tag.
+   1. Copy the release notes from [CHANGELOG.md](./CHANGELOG.md) for this
+      release version into the release description.
+1. Publish the release and ensure it builds and pushes to PyPI successfully.