Skip to content

Conversation

@mary-cleaton
Copy link
Contributor

Description

Update GitHub Actions workflows so that on push to main a package will be built and published on PyPI. This is still somewhat hypothetical as we don't have a PyPI account yet, but the code is pretty much ready.

Also updated a lot of documentation to reflect this change to the repository's deployment.

Type of change

  • Bug fix - non-breaking change
  • New feature - non-breaking change
  • Breaking change - backwards incompatible change, changes expected behaviour
  • Non-user facing change, structural change, dev functionality, docs ...

Checklist:

  • I have performed a self-review of my own code.
  • I have commented my code appropriately, focusing on explaining my design decisions (explain why, not how).
  • I have made corresponding changes to the documentation (comments, docstring, etc.. )
  • I have added tests that prove my fix is effective or that my feature works.
  • New and existing unit tests pass locally with my changes.
  • I have updated the change log.

Peer review

Any new code includes all the following:

  • Documentation: docstrings, comments have been added/ updated.
  • Style guidelines: New code conforms to the project's contribution guidelines.
  • Functionality: The code works as expected, handles expected edge cases and exceptions are handled appropriately.
  • Complexity: The code is not overly complex, logic has been split into appropriately sized functions, etc..
  • Test coverage: Unit tests cover essential functions for a reasonable range of inputs and conditions. Added and existing tests pass on my machine.

Review comments

Suggestions should be tailored to the code that you are reviewing. Provide context.
Be critical and clear, but not mean. Ask questions and set actions.

These might include:
  • bugs that need fixing (does it work as expected? and does it work with other code
    that it is likely to interact with?)
  • alternative methods (could it be written more efficiently or with more clarity?)
  • documentation improvements (does the documentation reflect how the code actually works?)
  • additional tests that should be implemented
    • Do the tests effectively assure that it
      works correctly? Are there additional edge cases/ negative tests to be considered?
  • code style improvements (could the code be written more clearly?)

Further reading: code review best practices

@mary-cleaton mary-cleaton requested a review from a team November 14, 2025 16:04
@mary-cleaton mary-cleaton self-assigned this Nov 14, 2025
@mary-cleaton mary-cleaton added documentation Improvements or additions to documentation github actions Pull requests that update GitHub Actions code labels Nov 14, 2025
@mary-cleaton mary-cleaton added the enhancement New feature or request label Nov 14, 2025
This is more secure than using an API key. Also, update so package is built for multiple package versions, currently 3.8-3.10.
Comment on lines +11 to +22
name: Build and verify release
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
with:
fetch-depth: 0
python-version: ["3.8", "3.9", "3.10"]

- uses: hynek/build-and-inspect-python-package@v2

# Publish to PyPI
pypi-publish:

Check warning

Code scanning / CodeQL

Workflow does not contain permissions Medium

Actions job or workflow does not limit the permissions of the GITHUB_TOKEN. Consider setting an explicit permissions block, using the following as a minimal starting point: {contents: read}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation enhancement New feature or request github actions Pull requests that update GitHub Actions code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants