Skip to content

Commit 545bd8e

Browse files
sduvvuri1603sduvvuri1603
committed
chore: formatting corrected
Signed-off-by: sduvvuri1603 <sduvvuri@redhat.com>
1 parent 2ac1680 commit 545bd8e

File tree

3 files changed

+160
-3
lines changed

3 files changed

+160
-3
lines changed

‎.github/workflows/build-packages.yml‎

Lines changed: 65 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,22 +1,47 @@
11
---
22
name: Build and Test Python Packages
33

4+
# Reusable build/validation workflow; callable via push/PR or workflow_call.
45
on:
56
push:
67
branches:
78
- main
8-
tags:
9-
- 'v*'
109
pull_request:
1110
branches:
1211
- main
12+
workflow_call:
13+
inputs:
14+
python_versions:
15+
description: 'JSON array of Python versions for the matrix, e.g. ["3.11","3.13"]'
16+
required: false
17+
type: string
18+
default: '["3.11","3.13"]'
19+
publish_packages:
20+
description: 'Set true to build from sdist and publish to PyPI'
21+
required: false
22+
type: boolean
23+
default: false
1324

1425
jobs:
1526
build:
1627
runs-on: ubuntu-24.04
28+
permissions:
29+
contents: read
30+
id-token: write # Required when publishing via Trusted Publishing
31+
# Flag release mode based on trigger inputs or tagged builds.
32+
env:
33+
SHOULD_PUBLISH: >-
34+
${{ (github.event_name == 'workflow_call' && inputs.publish_packages)
35+
|| (github.event_name != 'workflow_call'
36+
&& (github.ref matches '^refs/tags/v[0-9]+\\.[0-9]+\\.[0-9]+$')) }}
1737
strategy:
1838
matrix:
19-
python-version: ["3.11", "3.13"]
39+
python-version: >-
40+
${{ fromJson(
41+
github.event_name == 'workflow_call' && inputs.python_versions != ''
42+
? inputs.python_versions
43+
: '["3.11","3.13"]'
44+
) }}
2045
2146
name: Build packages (Python ${{ matrix.python-version }})
2247

@@ -31,7 +56,38 @@ jobs:
3156
with:
3257
python-version: ${{ matrix.python-version }}
3358

59+
# Release-mode builders regenerate artifacts from the sdist and validate metadata.
60+
- name: Install build tools for release artifacts
61+
if: env.SHOULD_PUBLISH == 'true'
62+
run: |
63+
python -m pip install --upgrade pip
64+
python -m pip install build twine
65+
66+
- name: Build release sdist
67+
if: env.SHOULD_PUBLISH == 'true'
68+
run: |
69+
rm -rf dist
70+
python -m build --sdist --outdir dist
71+
72+
- name: Rebuild wheel from sdist
73+
if: env.SHOULD_PUBLISH == 'true'
74+
run: |
75+
set -eux
76+
tmp_dir="$(mktemp -d)"
77+
sdist_path="$(ls dist/*.tar.gz)"
78+
tar -xzf "$sdist_path" -C "$tmp_dir"
79+
sdist_root="$(find "$tmp_dir" -mindepth 1 -maxdepth 1 -type d | head -n 1)"
80+
python -m build --wheel --outdir "$tmp_dir/dist" "$sdist_root"
81+
cp "$tmp_dir/dist"/*.whl dist/
82+
83+
- name: Run Twine checks
84+
if: env.SHOULD_PUBLISH == 'true'
85+
run: |
86+
python -m twine check dist/*
87+
88+
# Validation path: standard build/test workflow across matrix versions.
3489
- name: Build Package
90+
if: env.SHOULD_PUBLISH != 'true'
3591
run: |
3692
echo "Building package (kfp-components)..."
3793
uv build --out-dir dist/
@@ -72,3 +128,9 @@ jobs:
72128
name: package-py${{ matrix.python-version }}
73129
path: dist/
74130
retention-days: 30
131+
132+
- name: Publish to PyPI
133+
if: env.SHOULD_PUBLISH == 'true' && matrix.python-version == '3.11'
134+
uses: pypa/gh-action-pypi-publish@release/v1
135+
with:
136+
packages-dir: dist/

‎.github/workflows/release.yml‎

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
---
2+
name: Release Python Package
3+
4+
on:
5+
push:
6+
tags:
7+
- 'v*'
8+
9+
jobs:
10+
release:
11+
# Reuse build-packages.yml in publish mode for semver tags.
12+
if: ${{ github.ref matches '^refs/tags/v[0-9]+\\.[0-9]+\\.[0-9]+$' }}
13+
uses: ./.github/workflows/build-packages.yml
14+
secrets: inherit
15+
with:
16+
python_versions: '["3.11"]'
17+
publish_packages: true

‎docs/RELEASE.md‎

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
# Release Guide
2+
3+
This document describes how to publish the `kfp-components` package and how to react if a release needs to be withdrawn. Follow every step to keep automation, downstream consumers, and PyPI in sync.
4+
5+
## Versioning Strategy
6+
7+
We use [Semantic Versioning](https://semver.org/) for `kfp-components`.
8+
9+
- **Major** (`vX.0.0`): Breaking changes or alignment with a new Kubeflow Pipelines major release. Coordinate with the Pipelines Working Group before cutting a major.
10+
- **Minor** (`vX.Y.0`): New components, features, or dependency bumps that stay backward compatible.
11+
- **Patch** (`vX.Y.Z`): Bug fixes, metadata refreshes, or documentation-only updates.
12+
13+
All git tags **must be prefixed with `v`** (for example: `v1.11.0`). The GitHub Actions workflows ignore tags without that prefix, so `1.11.0` will not build or publish artifacts.
14+
15+
## Pre-release Checklist
16+
17+
1. Confirm the main branch is healthy: CI is green and `uv build` succeeds locally.
18+
2. Ensure all required documentation updates (including changelog entries if applicable) are committed.
19+
3. Make sure `pyproject.toml` already contains the release metadata you intend to publish (name, classifiers, dependencies).
20+
21+
## Release Procedure
22+
23+
1. **Update the version** in `pyproject.toml` under the `[project]` section.
24+
2. **Commit** the change with a message such as `chore: bump version to v1.11.1`.
25+
3. **Tag the commit** using the `v` prefix:
26+
27+
```bash
28+
git tag v1.11.1
29+
git push origin main
30+
git push origin v1.11.1
31+
```
32+
33+
4. Wait for GitHub Actions to finish (details below). Publish release notes on GitHub after the workflow succeeds.
34+
35+
## GitHub Actions Automation
36+
37+
Two workflows collaborate to ship a release.
38+
39+
### Build Validation (`.github/workflows/build-packages.yml`)
40+
41+
- **Trigger**: pushes to `main` and pull requests targeting `main`.
42+
- **Behavior**:
43+
- Uses a Python matrix (currently 3.11 and 3.13) to build, validate, and test the package.
44+
- Uploads the artifacts for inspection. No publish occurs.
45+
- **What it does**:
46+
- Builds wheel and source distributions with `uv build`.
47+
- Validates wheel contents and metadata.
48+
- Creates an isolated virtual environment and verifies that `kfp-components` installs and imports correctly.
49+
- Uploads the build artifacts as workflow artifacts for traceability.
50+
51+
### Release Pipeline (`.github/workflows/release.yml`)
52+
53+
- **Trigger**: pushes to tags that match `vX.Y.Z` (semantic versioning with a leading `v`).
54+
- **How it works**:
55+
- Calls the reusable `build-packages.yml` workflow with a single Python version (3.11) and `publish_packages=true`.
56+
- The reusable workflow switches into “release mode,” which:
57+
- Installs `build` and `twine`.
58+
- Builds an sdist (`python -m build --sdist`).
59+
- Unpacks the sdist into a temporary directory.
60+
- Rebuilds the wheel using the unpacked sdist contents.
61+
- Runs `twine check` on the sdist and wheel.
62+
- Performs the same validation and import smoke tests as the main workflow.
63+
- Uploads the artifacts for auditing.
64+
- Publishes the release to PyPI via Trusted Publishing (GitHub Actions OIDC), so no manual credential management or `twine upload` step is required.
65+
66+
If the workflow fails, do not push a PyPI release. Fix the failure, retag (or tag a new patch version), and rerun the pipeline.
67+
68+
## Rollback Procedure (Yanking a Release)
69+
70+
PyPI does **not** support deleting releases. If a published version is broken:
71+
72+
1. Sign in to [pypi.org](https://pypi.org/) with an account that has maintainer or owner rights on `kfp-components`.
73+
2. Navigate to the project → **Release history**, select the release that needs to be withdrawn, and choose **Yank release**.
74+
3. Provide a brief explanation for the yank (PyPI will display this note to installers) and confirm.
75+
4. Communicate the issue in GitHub (discussion or release notes) and plan a follow-up patch release (for example `v1.11.2`) with the fix.
76+
5. Tag and publish the new patch release following the standard procedure.
77+
78+
Do **not** attempt to reuse a yanked version number. Always increment the patch version for the corrective release.

0 commit comments

Comments
 (0)