You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Problem
A good release process needs to be fast while also ensuring quality and
consistency. Confidence of quality comes from incorporating automated
testing. And there are many aspects of consistency including:
- Ensuring commits are tagged with version number so we can know what is
in each release (now and in the future in case of any security reports)
- Version number in `pinecone/__version__` is correctly updated, so we
don't try to reuse the same one later
- Building in a standardized way to avoid introducing accidental
inconsistencies (e.g. uncommitted and untested local changes
accidentally included in a release, using an old version of python on a
local machine, etc)
## Solution
Implement github actions workflows for publishing releases
(`release.yaml`) and prereleases (`alpha-release.yaml`).
<img width="649" alt="Screenshot 2023-06-06 at 3 01 23 PM"
src="https://github.com/pinecone-io/pinecone-python-client/assets/1326365/79e2464a-832c-447d-a771-146dc6d60ecf">
These workflows both follow the same high-level steps that take place in
a `publish-to-pypi.yaml` [reusable
workflow](https://docs.github.com/en/actions/using-workflows/reusing-workflows):
- Run tests using another new reusable workflow, `testing.yaml`, which I
refactored out of the existing PR workflow.
- Automatic version bumps based on type of release (`major`, `minor`,
`patch`).
- I ended up writing my own small action to do this because I didn't
find a nice github action that would do this off the shelf. There are
lots of small code packages out there that do the version bump logic but
they tended to have weird flaws that made them a poor fit (e.g. wanting
to handle the git commit part even though this isn't the right moment
for it in my workflow, wanting to store separate version-related config
elsewhere, poor support for custom alpha/rc version numbers, etc.)
- Check that version numbers are unique (i.e. that there is no
preexisting git tag with that number. This mainly protects us from
accidentally reusing the same rc number). This validation is possible
since git tags become the source of truth on which version numbers are
used/available.
- Build with existing make task
- Upload to PyPI using twine. This is no change, just using Makefile
tasks defined by others in the past.
- Git push commit with updated `pinecone/__version__` and git tags. Save
this step for last so that the git tag is not consumed unless the pypi
upload is successful.
## Other notes
Updated the version saved in `pinecone/__version__` because I noticed
that it is out of date with the latest version published on PyPI. This
is one example of a type of error that will no longer occur when
publishing from CI.
While implementing this I ran into several different issues in github
actions including:
- actions/runner#2472
- actions/runner#1483
- actions/hello-world-javascript-action#12
## Future Work
Some ideas for future:
- I would like to make some automated changelog updates and draft
release notes from CI. But not doing this now as this is already a large
change.
- I could also do some work to figure out what the automatic next rc
number is by inspecting what git tags have been used. But for now it's
easy to just pass in the values as an input when starting the job.
## Type of Change
- [x] Infrastructure change (CI configs, etc)
## Test Plan
I used the test environment at test.pypi.org to publish an rc version of
this package using the `alpha-release.yaml` version of the workflow.
Here's a [test
run](https://github.com/pinecone-io/pinecone-python-client/actions/runs/5192266625)
I did that targeted the testpypi and resulted in [this 2.2.2rc4
artifact](https://test.pypi.org/project/pinecone-client/2.2.2rc4/).
Which can be installed like this by specifying the test.pypi.org index:
```
pip install -i https://test.pypi.org/simple/ pinecone-client==2.2.2rc4
```
In general, to test a github workflow that only exists in a branch you
need to install the github CLI and run a command like this from inside
the project:
```
gh workflow run alpha-release.yaml -f ref=jhamon/release-from-ci -f releaseLevel=patch -f prereleaseSuffix='rc4'
```
The only thing I changed after this run was to switch from targeting the
test PyPI index to the production PyPI index.
The prod workflow is substantially similar so I have a high confidence
it should work but I don't want to test it and release until I land this
in master because I want to the release commit to tag a SHA in the main
history (and not this branch). I plan to land, then make a follow up for
any small issues that come up when trying to use it for the first time.
0 commit comments