ci: autorelease python client

[daquinteroflex]

Works per:

• https://github.com/flexcompute/tidy3d/actions/runs/19425938694
• https://github.com/flexcompute/tidy3d/actions/runs/19227233133

Also see https://github.com/flexcompute/compute/pull/2814

Greptile Summary

• Implements automated release workflow with modular stages for tag creation, testing, and deployment to TestPyPI/PyPI
• Release type parameter mismatch between workflows causes version validation to never execute for production releases
• Critical deployment steps (PyPI publishing, GitHub release creation) are commented out as placeholders

Confidence Score: 3/5

• This PR has critical issues that need resolution before production use
• While the workflow architecture is well-designed with good separation of concerns, there are blocking issues: (1) release_type parameter mismatch that breaks version validation, (2) PyPI deployment and GitHub release creation are commented out, (3) using insecure token auth instead of OIDC trusted publishing. These issues prevent the workflow from functioning as intended for production releases.
• Pay close attention to tidy3d-python-client-release.yml (release_type mismatch), tidy3d-python-client-deploy.yml (commented deployment steps), and verify the parameter passing between workflow files

Important Files Changed

Filename	Overview
.github/workflows/tidy3d-python-client-deploy.yml	New deployment workflow with TestPyPI/PyPI publishing steps, but PyPI deployment is commented out and TestPyPI uses insecure authentication instead of trusted publishing
.github/workflows/tidy3d-python-client-create-tag.yml	New tag creation workflow with version validation for final releases, properly handles tag recreation and uses secure token authentication
.github/workflows/tidy3d-python-client-release.yml	Main release orchestration workflow with complex stage control logic, but GitHub release creation step is commented out and sync logic has incomplete implementation

Sequence Diagram

sequenceDiagram
    participant User
    participant Release as "Release Workflow"
    participant CreateTag as "Create Tag"
    participant Tests as "Test Workflow"
    participant Deploy as "Deploy Workflow"
    participant DocsSync as "Docs Sync"
    participant PyPI as "PyPI/TestPyPI"
    
    User->>Release: "Trigger workflow_dispatch with release_tag"
    Release->>Release: "Validate tag format"
    Release->>Release: "Determine workflow scope (stages, test suites, deployment targets)"
    
    alt run_tag == true
        Release->>CreateTag: "Call create-tag workflow"
        CreateTag->>CreateTag: "Validate version match (if release_type==final)"
        CreateTag->>CreateTag: "Delete existing tag if present"
        CreateTag->>CreateTag: "Create and push tag"
        CreateTag-->>Release: "Tag created"
    end
    
    alt run_tests == true
        Release->>Tests: "Call python-client-tests with release_tag"
        Tests->>Tests: "Checkout code at release_tag"
        Tests->>Tests: "Run local tests, remote tests, CLI tests"
        alt submodule_tests enabled
            Tests->>Tests: "Run submodule integration tests"
        end
        Tests->>Tests: "Validate all test results in workflow-validation job"
        Tests-->>Release: "Tests passed"
        Release->>Release: "Compile test results and set proceed_deploy flag"
    end
    
    alt run_deploy == true && tests passed
        Release->>DocsSync: "Call docs-sync workflow with source_ref=release_tag"
        DocsSync->>DocsSync: "Push to ReadTheDocs mirror repo"
        DocsSync-->>Release: "Docs synced"
        
        alt deploy_pypi == true || deploy_testpypi == true
            Release->>Deploy: "Call deploy workflow"
            Deploy->>Deploy: "Build package from release_tag"
            alt deploy_testpypi == true
                Deploy->>PyPI: "Publish to TestPyPI"
            end
            alt deploy_pypi == true
                Note over Deploy: "PyPI deployment currently commented out"
            end
            Deploy-->>Release: "Deployment complete"
        end
    end

Loading

[greptile-apps]

_{13 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile
React with 👍 or 👎 to share your feedback on this new summary format}

[github-actions]

Diff Coverage

Diff: origin/develop...HEAD, staged and unstaged changes

No lines with coverage information in this diff.

[yaugenst-flex]

Thanks @daquinteroflex this looks great but I also don't really understand what's going on, so hard to give a proper review. Could we have someone from infra also have a look?

[daquinteroflex]

Sorry I couldn't push further polishing yesterday after github went down so I've actually addressed several of your points already

[daquinteroflex]

Sure maybe @bryance-flexcompute can give some thoughts

[daquinteroflex]

@greptile reassess

[greptile-apps]

Looking at this PR, I can see it implements automated release workflows for the Tidy3D Python client. Let me reassess the changes:

Updated Assessment

This PR introduces a comprehensive automated release system with well-structured, modular workflows. However, there are still some critical issues that need attention:

✅ Strengths

1. Excellent Modular Design: The workflow architecture is well-designed with clear separation of concerns
2. Comprehensive Documentation: The README.md and version.rst files provide excellent documentation
3. Robust Error Handling: Good validation and error handling throughout
4. Flexible Control: The workflow_control parameter allows resuming from different stages
5. Security Improvements: Uses secure token authentication in most places

❌ Critical Issues Identified

1. Release Type Parameter Mismatch in tidy3d-python-client-create-tag.yml:

   # Line 56: This condition will NEVER be true for production releases
   if: ( env.RELEASE_TYPE == 'pypi' ) || ( env.RELEASE_TYPE == "testpypi" )

   The main workflow passes release_type: final but the validation checks for pypi/testpypi. This means version validation will never run for production releases.

2. Commented Out Critical Steps in tidy3d-python-client-deploy.yml:

   # Line 193: PyPI deployment is commented out
   echo "   View at: https://pypi.org/project/tidy3d/"

3. Insecure Authentication: Using token-based auth instead of OIDC trusted publishing for PyPI

4. Missing GitHub Release Creation: The release creation step is commented out in the main workflow

🔧 Required Fixes

1. Fix Parameter Mismatch:

   # In tidy3d-python-client-create-tag.yml, change line 56:
   if: ( env.RELEASE_TYPE == 'final' )

2. Enable PyPI Deployment: Uncomment and fix the PyPI deployment steps

3. Enable GitHub Release: Uncomment the GitHub release creation step

4. Consider OIDC: Migrate to trusted publishing for better security

Confidence Score: 3.5/5

The workflow architecture is solid and well-documented, but the parameter mismatch and commented-out deployment steps are blocking issues that prevent the workflow from functioning correctly for production releases. These need to be fixed before this can go to production.

The PR shows excellent engineering practices in terms of modularity, documentation, and error handling, but has implementation gaps that need addressing.

[daquinteroflex]

@greptile check the updates in the code and reassess

[greptile-apps]

Looking at this comprehensive PR that implements an automated release workflow, I can see significant improvements and additions. Let me analyze the key changes:

Major Improvements ✅

1. Comprehensive Workflow Architecture

• Well-designed modular approach with separate workflows for tagging, testing, and deployment
• Clear separation of concerns between components
• Good use of workflow_call for reusability

2. Enhanced Testing Integration

• Integrated CLI tests, submodule tests, and version consistency checks
• Centralized validation through workflow-validation job
• Proper test gating for deployments

3. Better Documentation

• Excellent README in .github/workflows/ explaining the entire system
• Clear parameter descriptions and usage examples
• Good troubleshooting guidance

Critical Issues Identified 🚨

1. Release Type Parameter Mismatch
In tidy3d-python-client-create-tag.yml:

# workflow_dispatch uses:
options: [draft, testpypi, pypi]

# But workflow_call expects:
# release_type: final  # This will never match 'pypi'

And the validation logic checks:

if [[ "$RELEASE_TYPE" == 'pypi' || "$RELEASE_TYPE" == 'testpypi' ]]; then

But the create-tag workflow will never receive 'final' when called from the release workflow, so version validation may not work properly for production releases.

2. Commented Out Critical Deployment Steps
In tidy3d-python-client-deploy.yml, line 192:

# PyPI deployment is commented out
echo "Successfully published to PyPI"
          echo "   View at: https://pypi.org/project/tidy3d/"  # This line is broken

3. Security Concerns

• Using token-based auth instead of OIDC trusted publishing for PyPI
• secrets: inherit usage in multiple places (though zizmor exceptions are noted)

4. Missing Functionality
In tidy3d-python-client-release.yml:

• GitHub release creation step references are commented out
• Branch sync logic appears incomplete

Recommendations for Production Readiness 🔧

1. Fix Parameter Alignment: Standardize release_type values between workflows
2. Uncomment PyPI Deployment: Enable actual PyPI publishing
3. Fix Syntax Error: Line 192 in deploy workflow has incorrect indentation
4. Implement Trusted Publishing: Replace token auth with OIDC for better security
5. Test End-to-End: Run complete flow in a test environment before production use

Assessment Update 📊

The PR shows significant architectural improvements and comprehensive planning, but still has critical blocking issues for production use. The workflow design is sound, but the implementation has gaps that would prevent successful releases.

Updated Confidence Score: 3.5/5 (improved from 3/5)

• Architecture and documentation are excellent (+0.5)
• But deployment and parameter issues remain critical blockers
• The foundation is solid and close to production-ready with fixes

The PR demonstrates good engineering practices and thorough planning, but needs the critical issues resolved before it can reliably handle production releases.

[daquinteroflex]

@greptile look at code changes again

[greptile-apps]

Looking at the code changes in this PR, I can see this implements a comprehensive automated release workflow system for the Tidy3D Python client. Here's what I observe:

Key Changes Summary

New Release Workflow Files:

1. tidy3d-python-client-release.yml - Main orchestration workflow
2. tidy3d-python-client-create-tag.yml - Tag creation with version validation
3. tidy3d-python-client-deploy.yml - Package deployment to PyPI/TestPyPI
4. Workflow documentation - Comprehensive README and version guide

Major Issues I Notice:

1. Critical Parameter Mismatch

In tidy3d-python-client-create-tag.yml, line 57:

if: env.RELEASE_TYPE == 'pypi' || env.RELEASE_TYPE == 'testpypi'

But the main release workflow uses different values:

options:
  - draft
  - testpypi  # This matches
  - pypi      # But main workflow uses 'final' not 'pypi'

This means version validation will never run for production releases since the release workflow passes final but the tag workflow expects pypi.

2. Deployment Issues

In tidy3d-python-client-deploy.yml:

• PyPI deployment step is commented out (lines would be around deployment section)
• Using insecure token authentication instead of OIDC trusted publishing
• Critical deployment functionality is incomplete

3. Incomplete Implementation

In tidy3d-python-client-release.yml:

• GitHub release creation step is commented out
• Sync logic has gaps in implementation
• Some workflow stages may not execute as intended

Positive Aspects:

• Well-structured modular design
• Comprehensive test integration
• Good separation of concerns between workflows
• Detailed documentation and examples

Recommendation: The parameter mismatch between final and pypi needs to be resolved, and the commented-out deployment steps should be completed before this can work in production.

[daquinteroflex]

So this PR does a few things that are coupled together:

• integrates all our tests into a common testing action
• creates a autorelease action that checks the source of truth
• introduces the tidy3d-extras into poetry lock in order to enable testing the dependency resolution (eventually integration tests too, but kept that separately)
• just keep remote tests for merge_queue or manual checks
• introduces more release checks to avoid previous issues
• implements test workflow-validation dependent on event, like release events require further validation from prs

I think greptile is confused since literally there is no reference to the issues it raises now

[daquinteroflex]

Full action works as intended for the 2.9.3 testpypi release https://github.com/flexcompute/tidy3d/actions/runs/19499962664

If it sounds ok think that's probably good enough for it to be merged since it captures a lot of the current release logic required that we do anyway manually
https://test.pypi.org/project/tidy3d/2.9.3/

[bryance-flexcompute]

Sure maybe @bryance-flexcompute can give some thoughts

I'd love to review it but realistically I'm gonna go on vacation tomorrow until Dec 1 and probably don't have time today to review a 2000 line PR 😄

Looks like great work though!