Workflow standards

Test coverage reporting

An approach using native github actions and with no dependence on external service (suitable for public/private repo.).

UI

PR comment when coverage decreases:

View the full coverage report html by looking at the uploaded artifact:

View your pytest coverage report:

How is this done

1. run pytest coverage report, generating a html report as well as capturing the stdout summary (writing that to a file).

   pytest --cov=dagrunner --cov-report=term --cov-report=html | tee coverage_output.txt; test ${PIPESTATUS[0]} -eq 0
   

2. Get coverage report for master/main.

• if master/main has changed:
  • Checkout master/main
  • Run pytest coverage report.
• else:
  • Get cached coverage report.

3. Compare coverage reports.

• if Coverage has decreases:
  • Submit a bot comment to the PR with details of this decrease.
  • Upload stdout summary file and html coverage report build as artifact.
• else:
  • Do nothing.

Look at the dagrunner github action here

ToDo

Pushing the coverage report to a special branch, avoiding the user from having to download the artifact. This will mean that the coverage report is directly viewable through github (linked to it from the bot comment).

pre-commit usage

https://github.com/MetOffice/dagrunner/blob/09404c3d4088646fff8e33310957b5a0a9d41d14/.pre-commit-config.yaml

In particular:

• ruff formatter (drop-in replace to black).
• ruff linter.
• copyright header checker (automatically adds them when missing).
  • https://github.com/MetOffice/dagrunner/blob/main/copyright_check
• Check __init__.py files present under all sub-packages.
  • https://github.com/metoppv/improver/blob/74ded1ce5c42bd9ce5f1ea2ca43e6b0e129be5e7/init_check

documentation

Using githubs native markdown rendering capability. Just needed a small script to extract docstrings to generate reference documentation. https://github.com/MetOffice/dagrunner/wiki/DAGrunner-documentation

Handling other repositories containing parallel development branches

Working practices around naming conventions in those other repositories and the action automatically checking out the relevant branch and prioritising your personal fork too.

Let's say repoA is dependent on repoB. For this reason, an optional workflow is supported via github actions to hook into an repoB development branch of the same name as repoA. This facilitates making changes between the two repositories.

For this reason, it is suggested a dependent improver development branch has the same name as the repoA development branch that depends on it. To better explain this concept, see the following:

Demonstrated this working successfully in improver_suite and [paraflow].(https://github.com/MetOffice/paraflow)

Presenting differences between package builds

Even constructing a URL pointing to the action job output step was involved.

Future

• rose/cylc environment action (creates a rose/cylc environment by simply specifying the version).
  • There is more to rose/cylc setup than simply a conda environment (wrapper scripts etc.).

Making the following private repositories public (complete the request following this meeting, if no objections):

Hopes of raising standards, avoiding duplication and raising awareness.

• https://github.com/MetOffice/pp-pre-commit-hooks
• https://github.com/MetOffice/pp-actions-common

Potentially a repository for the simple markdown ref documentation parser.

A repository for functionality used across our repositories for generating argparse from a function/class:

    args, kwargs = function_to_argparse_parse_args(<function/class>)
    <function/class>(**args, **kwargs)()

Supports all native python types and also *args, **kwargs etc. with optional arguments too, without any clize.

More:

pyproject.toml, pip installable, managing installations for lower bound package pinning through pyproject.toml - pip install .[lower]