Pypi release can be now automated.

[sei-vsarvepalli]

Related to #1175 - The pypi branch requires that we modify pyproject.toml

To release a project to pypi

1. Ensure a Tag is created in claver like format currently date +%Y.%-m.%-d%H%M
2. Push the updates to the branch pypi - then it will use OIDC authentication to publish the software to pypi

@ahouseholder - please make sure the pyproject.toml changes are okay with you. This is required to ensure that pypi package grabs the required files from "src/" directory.

[Copilot]

Pull request overview

This PR enables automated publishing of the certcc-ssvc package to PyPI via GitHub Actions OIDC, and updates setuptools configuration so the package is correctly discovered from the src/ layout.

Changes:

• Update pyproject.toml setuptools configuration to use src/ as the package root (package-dir + find.where).
• Add a new GitHub Actions workflow to build distributions on timestamp-like tags and publish them to PyPI using OIDC.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
pyproject.toml	Adjusts setuptools package discovery to package from src/ correctly for PyPI builds.
.github/workflows/pypi_publish.yml	Adds CI workflow to build sdist/wheel artifacts and publish to PyPI via OIDC on tag pushes.

[sei-ahouseholder]

since this is a glob pattern and not a regex, should we use "20??.*.*" instead to ensure we don't match on non-calver patterns?

[sei-ahouseholder]

I think the original #1175 is underspecified. See my comment there on why I don't think on push tags 20* is the right way to go, but we need to decide on which of a few alternative paths to take from here.

[ahouseholder]

Following conversations with the team, we're good with merging this PR. There's a need for a follow-on issue to resolve how we're using CalVer (see ADR-0013 because this seems to change what we need to do, but we haven't reached a full resolution on how we intend to increment versions yet. (I.e., are we going to "pure timestamp" CalVer like 2026.6.221541, or do we stick with some concept of "major is always year, but we only change minor to represent a significant change -- so 2026.6.3 might actually come in July 2026 if it's just a small change from the 2026.6.0 release), but if it were a bigger release it would be 2026.7.0. We've basically been operating under the assumption that only the YYYY.M.0 release has to fall in the month indicated, and we can increment the patch release as needed between bigger .0 releases. The pypi versions are using YYYY.-m.-dHHMM format though, so that contradicts ADR-0013. The resolution isn't necessarily to just comply with ADR-0013, it's to re-evaluate whether ADR-0013 is serving our needs now, and decide whether to supersede it with a new ADR or not.

@sei-vsarvepalli is planning to create a new issue to capture this concern for future consideration.