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

[adityamehra]

Summary

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

How it works

• PR push: automatically publishes 0.1.0.dev<run_number> to Test PyPI — clean version (e.g. 0.1.0) is never consumed and stays available for the real release
• workflow_dispatch with version: publishes the exact version supplied
• workflow_dispatch without version: publishes whatever is in pyproject.toml as-is

Notes

• Matches the pending Trusted Publisher on test.pypi.org (workflow: release-splunk-ao-adk-test.yaml, environment: testpypi)
• Builds with python -m build (hatchling backend)
• No service account / PAT needed

Made with Cursor

[adityamehra]

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

SHA pinning — All action references (actions/checkout, actions/setup-python, astral-sh/setup-uv, actions/upload-artifact, actions/download-artifact, pypa/gh-action-pypi-publish) are now pinned to full commit SHAs, matching the supply-chain convention established in ci-tests.yaml.

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.

[fercor-cisco]

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

Verdict: request_changes — Unscoped pull_request trigger publishes a Test PyPI dev release on every PR in the monorepo, fork PRs will fail at the OIDC publish step, and re-runs collide on the version.

General Comments

• 🟠 major (design): This workflow triggers on pull_request with no paths: filter, so every PR in the monorepo — including PRs that only touch the root splunk-ao package, docs, or other workflows — will run the test/build/publish jobs and push a 0.1.0.dev<run_number> release to Test PyPI. Both existing workflows (ci-tests.yaml, ci-tests-splunk-ao-adk.yaml) scope their pull_request triggers with paths:. Recommend adding paths: ['splunk-ao-adk/**', '.github/workflows/release-splunk-ao-adk-test.yaml'] so only relevant PRs consume Test PyPI versions and CI minutes. The test job here also duplicates the tests already run by ci-tests-splunk-ao-adk.yaml on adk PRs — consider whether the release workflow needs to re-run them.
• 🟠 major (security): Publishing on pull_request interacts badly with forks. This is a public repo with existing forks. For PRs from forks, GitHub grants a read-only token and does not issue an OIDC id-token, so the Publish to Test PyPI job (which needs id-token: write) will fail — giving external contributors a permanently red CI check. It also means arbitrary PR-supplied code runs in the build job before the publish step. Consider whether Test PyPI publishing should happen on PR events at all, or only on push-to-main / workflow_dispatch, leaving plain test/build for PR validation.
• 🟡 minor (design): No concurrency: group is defined, unlike ci-tests.yaml and ci-tests-splunk-ao-adk.yaml which both use group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }} with cancel-in-progress: true. Rapid consecutive PR pushes will run redundant publishes in parallel. Add a concurrency group for consistency and to avoid wasted publishes.

Follow-ups

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

• .github/workflows/release-splunk-ao-adk-test.yaml:93-96: The build step uses pip install build + python -m build against the setup-python interpreter, while the rest of the repo (test job, CI workflows) standardizes on uv. Consider using uv build for tooling consistency, or at minimum pin the build version rather than installing latest unpinned.

[fercor-cisco]

🟡 minor (bug): Test PyPI (like PyPI) rejects re-uploading a file for a version that already exists. The PR version is keyed on github.run_number, which stays constant across re-runs (only run_attempt changes). So re-running a failed/succeeded workflow run will fail the publish step with a 400 File already exists error. Add skip-existing: true to make re-runs idempotent.

Suggested change

	- name: Publish to Test PyPI
	uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # release/v1
	with:
	repository-url: https://test.pypi.org/legacy/
	verbose: true
	print-hash: true
	- name: Publish to Test PyPI
	uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # release/v1
	with:
	repository-url: https://test.pypi.org/legacy/
	skip-existing: true
	verbose: true
	print-hash: true

🤖 Generated by Astra

[fercor-cisco]

🟠 major (design): The pull_request: trigger has no paths: filter. Scope it to the adk package (and this workflow file) so unrelated PRs don't publish dev releases to Test PyPI.

Suggested change

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

🤖 Generated by Astra