Add TestPyPI support for pre-releases

[saiboddu759]

Description

PR updates the GitHub Actions workflow (onpush.yml) to support publishing pre-release versions to TestPyPI before releasing to production PyPI. The workflow now:

• Triggers on both published and prereleased release types
• Publishes pre-releases to TestPyPI automatically when a pre-release is created
• Publishes stable releases to production PyPI when a full release is published
• Only deploys documentation for production releases (not pre-releases)

Related Issue

This enhancement allows testing package releases on TestPyPI before pushing to production PyPI, reducing the risk of errors in production releases.

Motivation and Context

Currently, releases go directly to production PyPI, which means any issues with the package or metadata aren't caught until after publication. This change introduces a testing phase where:

1. Pre-releases are published to TestPyPI first
2. The package can be tested from TestPyPI before final release
3. Only verified releases go to production PyPI
4. Documentation deployment is reserved for production releases only

This follows Python packaging best practices and provides a safety net for the release process.

How Has This Been Tested?

• Workflow syntax has been verified
• The conditional logic uses GitHub Actions standard event filtering (github.event.action)
• TestPyPI credentials need to be added as repository secrets: TEST_PYPI_USERNAME and TEST_PYPI_PASSWORD

Testing Steps:

1. Create a pre-release on GitHub (e.g., v1.0.0-rc1)
2. Verify the package is published to https://test.pypi.org/
3. Test installation from TestPyPI: pip install --index-url https://test.pypi.org/simple/ spark-expectations
4. Create a full release on GitHub
5. Verify the package is published to production PyPI
6. Verify documentation is deployed

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• [ X] New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [X ] My code follows the code style of this project.
• My change requires a change to the documentation.
• [ X] I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• [ X] All new and existing tests passed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.59%. Comparing base (2f60ea2) to head (2f750af).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #236   +/-   ##
=======================================
  Coverage   97.59%   97.59%           
=======================================
  Files          27       27           
  Lines        2826     2826           
=======================================
  Hits         2758     2758           
  Misses         68       68           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[rvprimer]

@saiboddu759 Are these usernames and passwords configured in Cerberus? TEST_PYPI_USER & TEST_PYPI_PASSWORD ?

[asingamaneni]

@saiboddu759 Are these usernames and passwords configured in Cerberus? TEST_PYPI_USER & TEST_PYPI_PASSWORD ?

No they should be in github secrets