Add Automation of Python SDK Release Process. #168
Conversation
…oject toml to fix wheel metadata and remove the need of version.py and replace with txt. Update scripts along with the change from .py to .txt
…ho owns the commit
| gpg_private_key: ${{ secrets.GPG_PRIVATE_KEY }} | ||
| git_user_signingkey: true | ||
| git_commit_gpgsign: true | ||
| git_tag_gpgsign: true |
There was a problem hiding this comment.
This should be the private key of the bot that we will add to the secrets.
There was a problem hiding this comment.
Changes look ok and I've looked at the linked workflows to see what's going on.
What's missing for me is how will a release process look like once these changes are in. What does the flow look like? Based on that I can easily identify if we've complicated some parts or not.
For example, I don't really understand the purpose of prep-release workflow. If it's manual, what does it add compared to how we do a release prep now? 🤔
| @@ -0,0 +1 @@ | |||
| 0.2.0 | |||
There was a problem hiding this comment.
Why do we need a version.txt file now? This feels a bit odd. If you want, it might be better to fetch the version from pyproject.toml file. If that's not possible, then better filenames can be version.py or if that doesn't work, .VERSION (check Kubernetes operator for an example).
| build-backend = "setuptools.build_meta" | ||
|
|
||
| [project] | ||
| name = "onepassword-sdk" |
There was a problem hiding this comment.
Might be worth adding the version here. We do that for Connect SDK for Python.
There was a problem hiding this comment.
A couple of questions here:
- Why did we choose to move to usinge
pyproject.toml? - A lot of this setup part has been moved to
pyproject.toml, right? If so, is there anything that should still live here even though we moved things?
There was a problem hiding this comment.
pyproject.toml is the standard and when we created the Python SDK... we used setuptools which is considered deprecated.
pyproject.toml doesn't have all the functionality that setuptools such as injecting custom functions like figuring out which shared library to include and other small things.
| workflow_dispatch: | ||
|
|
||
| jobs: | ||
| Release-SDK: |
There was a problem hiding this comment.
[nit]
I think a better common pattern for job names is kebab-case:
| Release-SDK: | |
| release-sdk: |
| run: python -m pip install --upgrade pip setuptools wheel | ||
|
|
||
|
|
||
| # Need to grab the SDK version for the wheel name | ||
| - name: Extract SDK Version |
There was a problem hiding this comment.
[nit]
You can remove one extra line:
| run: python -m pip install --upgrade pip setuptools wheel | |
| # Need to grab the SDK version for the wheel name | |
| - name: Extract SDK Version | |
| run: python -m pip install --upgrade pip setuptools wheel | |
| # Need to grab the SDK version for the wheel name | |
| - name: Extract SDK Version |
| build-sdist: | ||
| name: Build source distribution for Python SDK | ||
| runs-on: ubuntu-latest | ||
| if: github.event.pull_request.merged == true && contains(github.event.pull_request.head.ref, 'sdk-core/') |
There was a problem hiding this comment.
[nit]
Do we want to replace contains with startsWith since that reflects better what we're looking for?
The workflow will be as follows:
Our old flow was The prep workflow is kind of over complicated now that I see, what if remove the prep workflow and keep the |
This PR will automate our python wheel building and publishing to PyPi to a GitHub action. This action will run when the RC branches are merged. This has been tested on the fork of my branch here.
I kept the build-wheels.sh script as fallback incase the action ever breaks and we need to run it manually.
Our Python SDK will now only support MacOS 12 or greater due to some swift compatibility issues with our Rust Core.
To get this to work, we need to add a GPG key that has a valid user and email address with a passphrase which will be added into the Secrets of this repo.
On the Test RC MR below, you will see that the pipeline had the option to add release notes. I opted to remove that as GitHub's workflow manual job doesn't accept multiline strings whether its in the workflow dispatch or we grab it from the comments its a lot of workarounds and will make it messy. I feel like it will be easier to manually commit release notes.
The nice thing is the prep and release SDK flow can be incorprated into the Go SDK as well as the JS SDK.
Heres the MOmarMiraj#41 that I have on my fork which runs through this whole flow.
These are the specific jobs:
Prep the SDKs - https://github.com/MOmarMiraj/onepassword-sdk-python/actions/runs/14250538232
Release the SDKs on GitHub: https://github.com/MOmarMiraj/onepassword-sdk-python/actions/runs/14250560322"
Wheel Builder and Publisher to TestPyPi - https://github.com/MOmarMiraj/onepassword-sdk-python/actions/runs/14250577506