Deployment/PyPi publication considerations and workflow

[pacharanero]

Just starting a discussion about what preferences we would have regarding the publication workflow.

CI/CD

I'm assuming we would want some form of CI/CD setup, in the past @andylaw used Travis CI but in our chat a while back it was suggested we could switch to GitHub Actions. I'm happy with Actions if everyone else is.

Branches and deployment

The Travis CI setup deploys the staging branch to test.pypi.org and the main branch to the live pypi.org site, which seems like a good pattern. My initial PRs have been against main but in future I will PR against development
Hence:
development -> local testing
staging -> https://test.pypi.org/project/nhs-number/
main -> https://pypi.org/project/nhs-number/

Versioning

We should continue to use SemVer as per @andylaw's prior work. Some tools exist to auto-increment the version number, one is Bump2Version, and another is this neat mechanism using GitHub Actions and a workflow_dispatch trigger: https://www.seanh.cc/2022/05/21/publishing-python-packages-from-github-actions/#automatically-generating-the-next-version-number

Code coverage

Do we use coverage or CodeCov? I'm happy to use CodeCov if it is free for OSS projects (it seems to be) and adds additional features.

[pacharanero]

Update on this

• Testing now occurs for all pushes to, and PRs against, any branch. Tests are performed across a matrix of 5 Python versions, 3.7 thorugh to 3.11.
• Deployment is now achieved through GitHub Actions and is now working, for the staging -> test.pypi.org deploy. Once we are happy with this and confident about publication we and set up the same publication for live pypi.org.

[andylaw]

What happens if I try to push a commit to a branch and there are failing tests? Does the push fail?

[pacharanero]

The push would succeed, but on GitHub the 'tests' Action would fail and you would get an email to say it had failed.
It means you would get an early warning that something wasn't right, and could avoid merging those commits further onwards, or avoid merging a PR with failing tests.

[pacharanero]

The only outstanding part of this issue is some form of test coverage metric. I have used coverage before but not codecov, which I understand is a web tool which would enable us to show the coverage in a badge on GH?

Any views on what we should use?

[andylaw]

You mean the badge that's in the table at the top of the page at https://pypi.org/project/nhs-number/ under "Coverage"?

[pacharanero]

You mean the badge that's in the table at the top of the page at https://pypi.org/project/nhs-number/ under "Coverage"?

Yep, I saw this but do we need to do anything to that badge to make it work with the new repo name? GH automatically redirects but at present it's pointing to https://codecov.io/gh/andylaw/NhsNumberChecks/branch/main/graph/badge.svg which is the old repo name.

I had assumed the coverage metric there was from the old version, altough I would hope we have not regressed in terms of coverage in the new version.

[andylaw]

You're right - it does !!

Edit the Readme.md file and see what happens

[andylaw]

(and maybe break some tests or add some additional code to see if you can make the number changes)