Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
adityamehra merged 3 commits into from
Jun 29, 2026
Merged

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

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
162f7de
feat(ci): add PyPI release workflow for splunk-ao
adityamehra Jun 25, 2026
4a4b74a
chore: pin actions to commit SHAs and add version validation
adityamehra Jun 29, 2026
dcb3e26
fix: broaden version regex and add build job least-privilege permissions
adityamehra Jun 29, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions .github/workflows/release-splunk-ao.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
name: Release splunk-ao to PyPI

on:
workflow_dispatch:
inputs:
version:
description: 'Version to release (e.g., 0.1.0, 1.2.3). Must match the version in pyproject.toml or will override it.'
required: true
type: string

jobs:
build:
name: Build package
runs-on: ubuntu-latest
Comment on lines +12 to +14

@fercor-cisco fercor-cisco Jun 29, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 minor (security): The build job declares no permissions: block, so it inherits the repository's default GITHUB_TOKEN scope (often read/write). The publish job correctly scopes itself to id-token: write only. Given this PR's explicit supply-chain hardening focus (SHA pinning, OIDC publish), apply least privilege to the build job too — it only needs to read the checked-out repo. Consider adding permissions: contents: read to the build job (or a top-level workflow default).

Suggested change
build:
name: Build package
runs-on: ubuntu-latest
build:
name: Build package
runs-on: ubuntu-latest
permissions:
contents: read

🤖 Generated by Astra

@adityamehra adityamehra Jun 29, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point — added permissions: contents: read to the build job so it explicitly opts in to the minimum scope it needs rather than inheriting the repo-wide default. Applied the same to the test and build jobs across all five release workflows for consistency.

outputs:
version: ${{ steps.get-version.outputs.version }}
steps:
- uses: actions/checkout@v4

- name: Set up Python
uses: actions/setup-python@v5
with:
python-version: '3.11'

- name: Install Poetry
run: pipx install poetry==2.4.1

- name: Set version
env:
INPUT_VERSION: ${{ inputs.version }}
run: |
poetry version "$INPUT_VERSION"
sed -i "s/__version__ = \".*\"/__version__ = \"${INPUT_VERSION}\"/" src/splunk_ao/__init__.py

- name: Get current version
id: get-version
run: echo "version=$(poetry version --short)" >> "$GITHUB_OUTPUT"

- name: Build package
Comment on lines +33 to +45

@fercor-cisco fercor-cisco Jun 29, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 minor (bug): poetry version "$INPUT_VERSION" interprets bump keywords (major, minor, patch, premajor, etc.) as bump rules rather than literal versions, whereas the sed line always writes the literal input string. If a maintainer enters patch, poetry bumps 0.1.0 -> 0.1.1 in pyproject.toml while __init__.py gets __version__ = "patch" — the built artifact then ships mismatched versions. The input is also otherwise unvalidated, so a typo like 1.0 or a value containing //" silently produces a bad build or breaks the sed expression. Validate the input against a version pattern up front so both files stay in sync.

Suggested change
run: |
poetry version "$INPUT_VERSION"
sed -i "s/__version__ = \".*\"/__version__ = \"${INPUT_VERSION}\"/" src/splunk_ao/__init__.py
- name: Get current version
id: get-version
run: echo "version=$(poetry version --short)" >> "$GITHUB_OUTPUT"
- name: Build package
- name: Set version
env:
INPUT_VERSION: ${{ inputs.version }}
run: |
if ! printf '%s' "$INPUT_VERSION" | grep -Eq '^[0-9]+\.[0-9]+\.[0-9]+([abprc.][0-9]+)*$'; then
echo "::error::Invalid version '$INPUT_VERSION'; expected an explicit version like 0.1.0"
exit 1
fi
poetry version "$INPUT_VERSION"
sed -i "s/__version__ = \".*\"/__version__ = \"${INPUT_VERSION}\"/" src/splunk_ao/__init__.py

🤖 Generated by Astra

@adityamehra adityamehra Jun 29, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch — both issues are now addressed in the latest commit:

  1. Version format 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.

  2. pyproject.toml update via sed: Switched from poetry version "$INPUT_VERSION" to sed for the pyproject.toml bump. This makes both file updates symmetric and removes the ambiguity between Poetry bump-rule keywords and literal version strings entirely, matching the approach used in the splunk-ao-adk and splunk-ao-a2a workflows.

run: poetry build

- name: Upload distributables
uses: actions/upload-artifact@v4
with:
name: splunk-ao-${{ steps.get-version.outputs.version }}
path: dist/

publish:
name: Publish to PyPI
needs: build
runs-on: ubuntu-latest
permissions:
id-token: write # Required for OIDC trusted publishing
environment:
name: pypi
url: https://pypi.org/project/splunk-ao/

steps:
- name: Download distributables
uses: actions/download-artifact@v4
with:
name: splunk-ao-${{ needs.build.outputs.version }}
path: dist/

- name: Publish to PyPI
uses: pypa/gh-action-pypi-publish@release/v1

@fercor-cisco fercor-cisco Jun 29, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟠 major (security): This repo's ci-tests.yaml deliberately pins every third-party action to a full commit SHA (with comments explaining why). This new workflow breaks that convention: actions/checkout@v4, actions/setup-python@v5, actions/upload-artifact@v4, actions/download-artifact@v4, and most importantly pypa/gh-action-pypi-publish@release/v1 are all mutable refs. @release/v1 is a branch, so its tip can change under you. Since this is the highest-trust step in the repo (OIDC-authenticated publish to PyPI), pin it (and the other actions) to a SHA to match the established supply-chain posture.

Suggested change
uses: pypa/gh-action-pypi-publish@release/v1
- name: Publish to PyPI
uses: pypa/gh-action-pypi-publish@<full-commit-sha> # release/v1
with:
verbose: true
print-hash: true

🤖 Generated by Astra

@fercor-cisco fercor-cisco Jun 29, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adityamehra pinning third-party actions is indeed important for the security posture. Many recent high level exploits were introduced by compromising this supply chain.

@adityamehra adityamehra Jun 29, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed — this is an important supply-chain safeguard, especially for the PyPI publish step which runs with OIDC identity. All five action references (, , , , and ) have been pinned to their full commit SHAs with the version tag preserved as a comment, matching the pattern in ci-tests.yaml. Pushed in the latest commit.

with:
verbose: true
print-hash: true
Loading