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

[adityamehra]

Summary

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

How it works

1. Trigger manually from the Actions tab with a required version (e.g. 0.1.0)
2. Patches splunk-ao-adk/pyproject.toml and splunk-ao-adk/src/splunk_ao_adk/__init__.py locally with the supplied version (no commit back)
3. Builds with python -m build (hatchling backend)
4. Publishes to PyPI via OIDC Trusted Publisher — no stored API token needed

Notes

• Version input is required to prevent accidental releases
• Matches the pending Trusted Publisher on pypi.org (workflow: release-splunk-ao-adk.yaml, environment: pypi)
• No PR trigger — use the Test PyPI workflow for pre-release validation

Made with Cursor

[adityamehra]

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

SHA pinning — All action references (actions/checkout, actions/setup-python, 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 an upfront grep -Eq check that rejects anything that is not an explicit PEP 440 version number (e.g. 0.1.0, 1.2.3b1). Bump keywords like patch, major, or minor will now fail fast with a clear ::error:: message before touching any files.

[fercor-cisco]

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

Verdict: approve — Workflow is correct and follows established repo conventions (SHA-pinned actions, env-var version input, OIDC publish); remaining items are robustness/design improvements, not blocking bugs.

General Comments

• 🟡 minor (design): This workflow injects the version into pyproject.toml/__init__.py at build time without committing back or creating a git tag (acknowledged as intentional in the PR description). However, the package already ships a [tool.semantic_release] config in splunk-ao-adk/pyproject.toml with tag_format = "splunk-ao-adk-v{version}", which implies a tag-based release flow. The consequence of the manual approach: after a release there is no git tag or commit recording which source revision produced a given PyPI version, so release provenance is weak and it's possible to publish from an arbitrary/uncommitted branch state. Worth confirming this is the desired model vs. cutting a tag (even just git tag + push) so released versions are traceable.

Follow-ups

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

• .github/workflows/release-splunk-ao-adk.yaml:47-51: The Get current version step re-greps the file that was just written from the validated input. If the assertion-based hardening above is adopted, this step can set version=${INPUT_VERSION} directly into $GITHUB_OUTPUT, removing the round-trip through the file entirely.
• .github/workflows/release-splunk-ao-adk.yaml:18-19: The build job has no timeout-minutes, unlike ci-tests-splunk-ao-adk.yaml which caps each job at 30 minutes. Consider adding a timeout to both jobs to bail out on hangs (e.g. during pip install build/python -m build or the publish upload).
• .github/workflows/release-splunk-ao-adk.yaml:3-9: No concurrency group is defined. Two manual dispatches in quick succession (or for the same version) could race. A concurrency group keyed on the workflow name would serialize releases; the sibling CI workflow already uses this pattern.

[fercor-cisco]

🟡 minor (bug): The sed substitution is not verified to have actually matched. If the version = "..." line format in pyproject.toml ever drifts (e.g. no surrounding spaces, or version moved under a different table), sed silently no-ops, and the subsequent Get current version step greps the unchanged file. The result: the build/artifact/publish would proceed with the stale version rather than the requested one, with no error — a silent wrong-version release. Since the version is already validated, you can both simplify and harden by deriving the output directly from the validated input and asserting the file was patched.

Suggested change

	sed -i "s/^version = \".*\"/version = \"${INPUT_VERSION}\"/" pyproject.toml
	sed -i "s/__version__ = \".*\"/__version__ = \"${INPUT_VERSION}\"/" src/splunk_ao_adk/__init__.py
	- name: Get current version
	id: get-version
	run: |
	VERSION=$(grep '^version = ' pyproject.toml | sed 's/version = "\(.*\)"/\1/')
	echo "version=${VERSION}" >> "$GITHUB_OUTPUT"
	sed -i "s/^version = \".*\"/version = \"${INPUT_VERSION}\"/" pyproject.toml
	sed -i "s/__version__ = \".*\"/__version__ = \"${INPUT_VERSION}\"/" src/splunk_ao_adk/__init__.py
	if ! grep -q "^version = \"${INPUT_VERSION}\"" pyproject.toml; then
	echo "::error::Failed to set version in pyproject.toml — version line format may have changed."
	exit 1
	fi
	if ! grep -q "__version__ = \"${INPUT_VERSION}\"" src/splunk_ao_adk/__init__.py; then
	echo "::error::Failed to set __version__ in src/splunk_ao_adk/__init__.py."
	exit 1
	fi

🤖 Generated by Astra

[adityamehra]

Good catch — added grep -q assertions after each sed call to verify the substitution actually landed. If the version line format in pyproject.toml or the version file ever drifts, the step now fails loudly with a ::error:: annotation rather than silently continuing with the stale version. Applied to all three PyPI release workflows in PR #59.