feat(ci): add Test PyPI release workflow for splunk-ao-a2a

[adityamehra]

Summary

Adds .github/workflows/release-splunk-ao-a2a-test.yaml — a pipeline that builds and publishes the splunk-ao-a2a package to Test PyPI.

How it works

• PR push: runs tests → publishes 0.1.0.dev<run_number> to Test PyPI (clean version stays reserved)
• workflow_dispatch with version: runs tests → publishes the exact version supplied
• workflow_dispatch without version: runs tests → publishes whatever is in pyproject.toml

Job chain

test → build → publish (each step gates the next)

Notes

• All action references pinned to commit SHA (matching ci-tests-splunk-ao-a2a.yaml pattern)
• Matches the pending Trusted Publisher on test.pypi.org (workflow: release-splunk-ao-a2a-test.yaml, environment: testpypi)
• Builds with python -m build (hatchling backend)

Made with Cursor

[adityamehra]

Applied the same changesets from PR #48 to this workflow:

Version input validation — Added a grep -Eq check in the Override version step (manual workflow_dispatch path) that rejects anything that is not an explicit PEP 440 version number. Bump keywords like patch, major, or minor will fail fast with a clear ::error:: message before touching any files. The PR-triggered .dev path is unaffected since it computes the version automatically from pyproject.toml. (SHA pinning was already in place from the initial commit.)

[fercor-cisco]

🤖 This review was generated by the Astra agent (claude-opus-4-8). It may contain mistakes.

Verdict: request_changes — The unscoped pull_request trigger publishes a Test PyPI dev release on every PR across the whole monorepo, and the OIDC publish job will fail on all fork PRs.

Follow-ups

Suggested follow-up work that could be tracked as Shortcut stories:

• .github/workflows/release-splunk-ao-a2a-test.yaml:13-43: The test job duplicates the type-check + pytest steps already run by ci-tests-splunk-ao-a2a.yaml on the same pull_request event (single Python 3.11 vs. the CI matrix). Consider gating the release workflow's test job to run only on workflow_dispatch, or reuse the CI workflow via workflow_call, to avoid running the same tests twice on every PR.

[fercor-cisco]

🟠 major (design): The pull_request trigger has no paths filter, so this workflow runs — and publishes a new 0.1.0.dev<run_number> to Test PyPI — on every PR to the repo, including PRs that touch only splunk-ao-adk/, the repo root, docs, or other CI files. That both burns Test PyPI version numbers on unrelated changes and duplicates the test run already performed by ci-tests-splunk-ao-a2a.yaml. The sibling CI workflow scopes itself with paths: ['splunk-ao-a2a/**', ...]; this one should do the same so a dev release is only cut when the package actually changes.

Suggested change

	pull_request: # Publishes a .dev pre-release on every PR push
	pull_request: # Publishes a .dev pre-release on every PR push
	paths:
	- 'splunk-ao-a2a/**'
	- '.github/workflows/release-splunk-ao-a2a-test.yaml'

🤖 Generated by Astra

[fercor-cisco]

🟠 major (design): Because this runs on pull_request (not pull_request_target), PRs opened from forks run with a read-only GITHUB_TOKEN and are not granted id-token: write — GitHub downgrades OIDC permissions for fork PRs. The publish job will therefore fail for every external-contributor PR (the repo already has 2 forks), producing a persistent red check on those PRs. Consider gating the publish job so it is skipped for fork PRs, e.g. if: github.event_name == 'workflow_dispatch' || github.event.pull_request.head.repo.full_name == github.repository, so fork PRs still run test/build but don't attempt (and fail) the publish. This also avoids attempting a trusted-publish on untrusted code.

🤖 Generated by Astra

[fercor-cisco]

🟡 minor (design): Unlike every sibling workflow (ci-tests.yaml, ci-tests-splunk-ao-a2a.yaml), this one has no concurrency group. Pushing several commits to a PR in quick succession will launch overlapping runs that each publish a distinct .dev<run_number> to Test PyPI. Add a concurrency group with cancel-in-progress: true to match the existing pattern and avoid redundant publishes.

Suggested change

	on:
	pull_request: # Publishes a .dev pre-release on every PR push
	workflow_dispatch:
	inputs:
	version:
	description: 'Version to publish (e.g., 0.1.0, 1.2.3rc1, 1.2.3.post1). Must be an explicit version. Leave empty to use the version in pyproject.toml as-is.'
	required: false
	type: string
	on:
	pull_request: # Publishes a .dev pre-release on every PR push
	workflow_dispatch:
	inputs:
	version:
	description: 'Version to publish (e.g., 0.1.0, 1.2.3rc1, 1.2.3.post1). Must be an explicit version. Leave empty to use the version in pyproject.toml as-is.'
	required: false
	type: string
	concurrency:
	group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
	cancel-in-progress: true

🤖 Generated by Astra