upgrade to python 3.12, test versions 3.8 - 3.12

[johnjeffers]

Python 3.8 is EOL next month. Upgrading to latest stable version 3.12 gets us 4 more years. https://devguide.python.org/versions/

Other changes:

• run the tests as a matrix that tests python major versions 3.8 thru 3.12.
• rewrite the test workflow to use a github runner as self-hosted is not required
• rewrite the test workflow to run tests in a python venv to avoid warnings about running as root
• upgrade postgres version in docker compose file to 16.4

[robotdan]

We should probably update the dev setup to ensure 3.10 is installed on our dev boxes as well?

• https://github.com/FusionAuth/fusionauth-developer/blob/9f0195ab55be323ec039a597e4f361cc24ea2962/setup/core/globals.sh#L31

[johnjeffers]

Yep that's already in my plan, and literally the whole reason I started looking into this :)

[mooreds]

While you are in here, would be great to replace the bespoke docker compose setup with the released fusionauth github action.

Action here: https://github.com/marketplace/actions/fusionauth-action

Example using a kickstart: https://github.com/FusionAuth/fusionauth-theme-history-updater/blob/main/.github/workflows/update-theme-history.yml#L69

[johnjeffers]

While you are in here, would be great to replace the bespoke docker compose setup with the released fusionauth github action.

Action here: https://github.com/marketplace/actions/fusionauth-action

Example using a kickstart: https://github.com/FusionAuth/fusionauth-theme-history-updater/blob/main/.github/workflows/update-theme-history.yml#L69

Cool, will do

[mooreds]

Also how does this change get into the release notes? Do we need a tracking issue attached to the 1.54 milestone?

[johnjeffers]

Also how does this change get into the release notes? Do we need a tracking issue attached to the 1.54 milestone?

@robotdan @wied03 Correct me if I'm wrong, but I don't think this is going to have any impact to customers, as long as we continue to test older versions as well as new, which this PR addresses.

However... I'm not sure if I should be updating the version in build.savant or not for this change, or whether that should happen as part of the regular 1.54 release process. If not, let me know and I'll roll that back.

[wied03]

Also how does this change get into the release notes? Do we need a tracking issue attached to the 1.54 milestone?

@robotdan @wied03 Correct me if I'm wrong, but I don't think this is going to have any impact to customers, as long as we continue to test older versions as well as new, which this PR addresses.

BW: I agree it won't have an effect.

However... I'm not sure if I should be updating the version in build.savant or not for this change, or whether that should happen as part of the regular 1.54 release process. If not, let me know and I'll roll that back.

BW: I think ideally this PR targets develop, which is already at 1.54.0. Then when release happens, this would all be 'included' in that.

[wied03]

Also how does this change get into the release notes? Do we need a tracking issue attached to the 1.54 milestone?

Does it need to be? If the library is still tested with the version it was before, then I think its compatibility hasn't changed, right?

[robotdan]

I don't know if this needs to be in release notes unless there is a reason to think it will affect anyone. I think all this does it cause us to use a newer point version (semver compatible) to build our python client.

Anyone using this client presumably can still use a Python runtime older than this since it should be a compatible change as far as I am aware.