Decouple client release from Delphi release

[rzats]

Closes #1296.

Summary:

Semi-detaches the versioning of the Python client and delphi-epidata.

This means that a new version of the Python client is only released when changes are made to the client file - when this is the case, however, it is synced to the current delphi-epidata version.

For further details, see #1296 (comment).

Prerequisites:

• Unless it is a documentation hotfix it should be merged against the dev branch
• Branch is up-to-date with the branch to be merged with, i.e. dev
• Build is successful
• Code is cleaned up and formatted

[melange396]

should we use dorny/paths-filter here (and also in release-helper.yml) to match the usage in the covidcast-indicators repo? fewer dependencies and reinvented wheels make for easier support and maintenance.
https://github.com/cmu-delphi/covidcast-indicators/blob/a6ea00355d79a47cc09db8090f6e5121c718de0f/.github/workflows/create-release.yml#L32-L40
https://github.com/cmu-delphi/covidcast-indicators/blob/a6ea00355d79a47cc09db8090f6e5121c718de0f/.github/workflows/publish-release.yml#L31-L41

[rzats]

I can give it a go, it should support the same features as changed-files.

[dshemetov]

Pushed a merge from dev and resolved conflicts with #1470.

[rzats]

@melange396 @dshemetov this is ready once again! Here's an updated rundown of my CI tests as well.

For testing purposes, I've forked the delphi-epidata repository, then added the commit rzats@0e9500f to it. This is a version of this PR which enables create-release and release-helper within a fork, but also stubs out various destructive steps in the GitHub Action - like actually creating a PyPi release, for instance.

I then ran several mock releases within the same repository:

4.1.24

rzats#1

• Simply syncs main with dev.
• There is currently a client change in dev which is not in main, so all versions are bumped from 4.1.23 to 4.1.24.
• In the release-helper run, the "release Python client" step would be launched (if it wasn't stubbed out). https://github.com/rzats/delphi-epidata/actions/runs/9663538010

4.1.25

rzats#3

• Adds a simple change to README.md.
• There are no changes to the client, so Python client versions remain unchanged, while others are bumped from 4.1.24 to 4.1.25.
• In the release-helper run, the "release Python client" step would not be launched. https://github.com/rzats/delphi-epidata/actions/runs/9663582771

4.1.26

rzats#5

• Adds a simple change to delphi_epidata.py within the client.
• Python client versions are correctly bumped from 4.1.24 to 4.1.26, skipping over a missing version. Others are bumped from 4.1.25 to 4.1.26.
• In the release-helper run, the "release Python client" step would be launched. https://github.com/rzats/delphi-epidata/actions/runs/9663614960

[dshemetov]

So I looked over your fork and its associated PRs. The overall behavior looks to be consistent with what you describe and what you and George agreed on in #1296 (namely, Python client stays loosely coupled - it doesn't update if there are no changes to delphi_epidata.py or contents of .../packaging/pypi/, but then "catches up" to the main repo version when there is a change). No further notes from me.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[rzats]

@melange396 @dshemetov I've updated the PR again! Also reran the tests and updated the links here: #1465 (comment)

[melange396]

It looks like you tested this with just "patch" as the argument to "Create Release"... Did you try with "major" (or "minor") and an explicit version to make sure those do the right thing too?

[rzats]

@melange396 I ran some tests for these just now and everything's looking OK:

minor: rzats#7 4.1.26 → 4.2.0
major: rzats#9 4.2.0 → 5.0.0
custom: rzats#11 5.0.0 → 6.7.8; also changes the Python client to make sure it jumps to the right version