Auto Publish PyPi -CI/CD

[davisadam10]

Now that the core module is confirmed as working via pypi, we need to setup/extend some form of CI/CD so that when we merge to main and publish a new version, we not only spin up a new instance of the web app, but also publish a new version of the python module

[c-clark]

@scottdyer bumping this up since it's related to the convo during the ACES TSC meeting.

I know things are migrating over to ASWF at the moment, but it would be great to get this particular issue resolved so it can auto-publish to PyPi instead of you doing it manually. Let me know if you prefer to wait until after the ASWF transition though, I'm not sure how imminent that is.

[scottdyer]

@davisadam10 any thoughts on what the trigger should be? On push? On release? Something else?

[KelSolaar]

Should be on tag no?

[scottdyer]

Yes, that's my expectation.
We just haven't set any tags on the repo yet, so we'll need to make sure we do that along with incrementing versions in pyproject.toml

[davisadam10]

Yeah agree with Thomas, it should be on tag, and we have to make that incrementing the version in the pyproject a part of the release process.

I would make that part of the CI/CD its self, gets the value of the tag, replaces the version in the pyproject, does the publish and the release, and once its all successfull commit the change back onto main

[scottdyer]

@davisadam10 When I first read this, it seemed logical but upon trying to implement, I don't think it works (unless of course I'm misunderstanding your proposal). If the worklfow is triggered by a tag, then the version in the pyproject should already match the tag before the tag is pushed. If the workflow is extracting the version from the tag and updating the pyproject, then there will be a commit after the tag, which would not be included in the tag.

So I think, when we have a release update, we just need to be diligent about updating the version # in the pyproject before creating a matching tag.

However, for robustness, I will add a step to make the workflow check that the version number in the .toml and the number in the tag match.

[davisadam10]

Sorry scott I made a botch of that explanation

Was meaning just leave the code as a dev version and just injext it at build

import os
from setuptools import setup

version = os.environ.get("VERSION", "0.0.0-dev")
setup(name="yourpkg", version=version, packages=["yourpkg"])

But also were not shipping daily builds etc so I think if you do as suggested it’s gonna be fine especially if yiu add a check to make sure tag and version match because i always forget to update the version in the project lol

[KelSolaar]

Yes, this is how it should work, basically, check everything is gold, then the version is bumped in the various relevant places, might be two, e.g., pyproject.toml, __init__.py, then tag is created, this once pushed, triggers the release.

[scottdyer]

Thanks both of you. I've never done this before, so figuring out as I go. I did test successfully on my fork and using TestPyPI.
Opened a PR (#128) so I can be schooled on anything I did incorrectly 😁