search

kbatch-dev / kbatch

MIT License
19 stars 7 forks source link

Create pre-release process #42

Open iameskild opened 2 years ago

iameskild commented 2 years ago

At the moment, working through a pre-release process can be a little tricky given the differences between how Python and Helm handle pre-releases. Helm enforces a strict SemVer versioning scheme thus in order to cut a non-production (i.e. alpha/beta/RC) release, you must specify a pre-release in the following format:

<version core> "-" <pre-release>`

For example, 0.4.0-rc1.

This conflicts with how Python handles pre-releases. Python PEP 440 outlines the particular syntax that should be followed which also includes a discussion on version "normalization". According to Python PEP 440, pre-releases are normalized as follows: 0.4.0-rc1 becomes 0.4.0rc1.

Now because of these differences and the fact that the docker image is tagged using the python release version syntax, when the helm chart of the same pre-release version is pulled and installed, the container.image in deployment.yaml is unable to find this version. It's looking for 0.4.0-rc1 when it needs 0.4.0rc1.

To get this to work more smoothly, we can either add/update the tag using the docker/metadata-action or find a way to specify the tag in container.image in deployment.yaml.

minrk commented 6 days ago

Looking into this, two ways I see this being easier:

  1. version chart independently of Python package, then there's no need for tagging to match
  2. build kbatch-proxy image in the chart instead of (or in addition to) in the Python package repo

If we build both, the image in the chart could start out as a one-line Dockerfile, ensuring the right version:

FROM kbatch-dev/kbatch-proxy:$version

The main reason I see for building an image in the Python repo is continuous publishing, which we haven't done (though https://github.com/kbatch-dev/kbatch/pull/82 introduces it). If we're not doing that, I think there's little reason to build the image in the Python repo as opposed to the chart repo.

This could all be fairly straightforward by adding chartpress to the helm chart.

WDYT, @yuvipanda ?

minrk commented 2 days ago

Just created 0.5.0a1 with the new process, and it worked fine. Assuming making a kbatch-proxy package and chart release (not required to do together)

  1. tag kbatch repo with tbump, e.g. tbump 0.5.0a1
  2. publish a release via github Releases UI with autogen changelog (this is what triggers image tagging, push to PyPI)
  3. update appVersion in chart repo (use pep440 '0.5.0a1')
  4. publish helm-style semver tag on the chart repo (git tag -am "release 0.5.0 alpha 1" 0.5.0-alpha.1; git push origin 0.5.0-alpha.1)

Not all of these steps are required unless making a prerelease of the Python package and propagating it through to a release of the chart all at the same time. 1-2 publish a Python package release, 3 updates the chart, 4 tags the chart (chart version does not need to match appVersion). 1-2

minrk commented 2 days ago

Leaving this open only until I write that down in the docs, which I'll try to do tomorrow.