FAQ | This is a LIVE service | Changelog

Skip to content

move to using poetry for packaging

Dr Rich Wareham requested to merge issue-20-refresh-packaging into master

Marked as draft because the MR needs to have the hard-coded ref to the CI template branch removed once uis/devops/continuous-delivery/ci-templates!46 (merged) is merged.

There is a fair amount of diff-noise from this MR due to adding pre-commit formatting checks (and fixing them up to match). Individual commits have cleaner diffs.

Primarily this MR addresses #20 (closed) by moving to using poetry for packaging. This necessitated refreshing the versions of the google cloud client libraries we use. Some of them were truly ancient. Take the opportunity to bump the major version number and remove support for KMS secrets. Anything still using in-tree encrypted secrets needs to be migrated.

In addition we add pre-commit checks which can be used to run linters like isort and black over the code.

This MR makes use of a new template introduced by uis/devops/continuous-delivery/ci-templates!46 (merged) intended to provide support for standalone Python apps like this one. In particular it provides support for uploading packages to the GitLab package registry. This is now reflected in the logan install instructions.

https://gitlab.developers.cam.ac.uk/uis/devops/tools/logan/-/pipelines/345908 is an example of a pipeline created by this config which includes the tox test parallel execution and a successful publish of the logan package.

The tox-tests job is split out to run each tox environment in parallel:

image

This MR implements most of the task list from #20 (closed)

  • Add a poetry-based packaging
  • Add a basic pytest cofiguration
  • Add a tox configuration which runs pytest, coverage, and pre-commit in test mode.
    • Pytest should output test results in xunit form.
  • Add a pre-commit configuration which runs black, isort, line-ending checks, etc.
  • Use the existing pre-commit GitLab CI template.
  • Add GitLab CI configuration (with an eye to moving to common template to):
    • Build wheels and upload to the package registry
    • Tag images with the tool version

I've chosen not to tag container images because I think there's not really any time we'd want to use them. The only reason they get built is for dependency scanning purposes. As such, I've set the container expiration policy on this repo to only keep the most recently tagged image.

Closes #20 (closed)

Edited by Dr Rich Wareham

Merge request reports