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
.github/workflows/prep-release.yml
Outdated
| 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.
Can you clarify which fields exactly you would expect to have in the GitHub Secrets? i.e. the key & value for the secret.
As well as any other dependencies that we should take care of before merging this MR - would be nice to have a Dependencies section in the PR description.
There was a problem hiding this comment.
The Github secrets would have to have the GPG secret key from the bot we expect to push the release. Similar to how it is here, it would be GPG_PRIVATE_KEY as the key and the value would be the actual GPG key. Yes I can add that dependencies in the PR section.
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? 🤔
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 EDIT: This has been updated so please look at the description for the latest flow. |
Can we change the release docs to capture this? We want to make sure they are up to date with the latest process. |
fix nits Co-authored-by: Eduard Filip <[email protected]>
|
@MOmarMiraj I still don't see the release process documented anywhere. We have instructions in |
|
What's the reasoning behind still requiring to run two different manual jobs to get the thing working? I envision the flow to look like this:
WDYT? |
|
What is the likelyhood of the release process to not succeed? |
Very rarely the Python release scripts fail, I think what horia recommended is fine and will implement that. Only JS can get finnicky sometimes but that is out of scope for now. |
… update the logic as well as update the release readme.
I updated the
You are right, we can make this simplification and this has been done. |
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.
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 incorporated into the Go SDK as well as the JS SDK.
Heres the MOmarMiraj#50 that I have on my fork which runs through this whole flow.
These are the specific jobs:
Release the SDKs on GitHub - https://github.com/MOmarMiraj/onepassword-sdk-python/actions/runs/14983407609
The workflow will be as follows:
Add the release notes manually (adding the release notes with correct markdown is very difficult for some reason so didn't include this in the prep workflow)
Run the release workflow manual on the RC branch which will build and publish on pypi aswell and increment the build and version number.
Our old flow was
make prep-releasewhich would input the version + build + release notes (usually we would just skip this and add it manual)make build-wheelsthis would build all the wheels (but build it very incorrectly and it wouldn't work correctly)make release, we would also need to export our github token and have the pypi API token to publish on PyPi.Dependencies Required for this PR to work:
GPG_SECRET_KEYandPASS_PHRASEto the repository to be able to have signed commits when we have theprep-releaseandreleaseworkflows.