Contributing¶
First of all, thank you so much for contributing! 🎉 💯
This document contains guidelines on how to most effectively contribute within this repository.
If you are stuck, please feel free to ask any questions or ask for help.
Code of conduct¶
This project is governed by our code of conduct. By participating, you are expected to uphold this code. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to community leaders responsible for enforcement. Please open a new security advisory notice (using defaults or “n/a” where unable to fill in the form) to privately notify us of any incidents of this nature.
Development¶
This project leverages development environments managed by Python Poetry. We leverage interactions with the Docker through Python to achieve reproducible results through containers. We use pytest for testing and GitHub actions for automated tests.
Development setup¶
Perform the following steps to setup a Python development environment.
Install Python (we recommend using
pyenv
or similar)Install Poetry Environment:
poetry install
Linting¶
Work added to this project is automatically checked using pre-commit via GitHub Actions. Pre-commit can work alongside your local git with git-hooks
After installing pre-commit within your development environment, the following command also can perform the same checks within your local development environment:
% pre-commit run --all-files
We use these same checks within our automated tests which are managed by GitHub Actions workflows. These automated tests generally must pass in order to merge work into this repository.
Testing¶
Work added to this project is automatically tested using pytest via GitHub Actions. Pytest is installed through the Poetry environment for this project. We recommend testing your work before opening pull requests with proposed changes.
You can run pytest on your work using the following example:
% poetry run pytest
Making changes to this repository¶
We welcome anyone to use GitHub issues (requires a GitHub login) or create pull requests (to directly make changes within this repository) to modify content found within this repository.
Specifically, there are several ways to suggest or make changes to this repository:
Open a GitHub issue: https://github.com/WayScience/coSMicQC/issues
Create a pull request from a forked branch of the repository
Creating a pull request¶
Pull requests¶
After you’ve decided to contribute code and have written it up, please file a pull request. We specifically follow a forked pull request model. Please create a fork of this repository, clone the fork, and then create a new, feature-specific branch. Once you make the necessary changes on this branch, you should file a pull request to incorporate your changes into this (fork upstream) repository.
The content and description of your pull request are directly related to the speed at which we are able to review, approve, and merge your contribution. To ensure an efficient review process please perform the following steps:
Follow all instructions in the pull request template
Triple check that your pull request is adding one specific feature or additional group of content. Small, bite-sized pull requests move so much faster than large pull requests.
After submitting your pull request, ensure that your contribution passes all status checks (e.g. passes all tests)
Pull request review and approval is required by at least one project maintainer to merge. We will do our best to review the code addition in a timely fashion. Ensuring that you follow all steps above will increase our speed and ability to review. We will check for accuracy, style, code coverage, and scope.
Versioning¶
We use poetry-dynamic-versioning
to help version this software through PEP 440
standards.
Configuration for versioning is found within the pyproject.toml
file.
All builds for packages include dynamic version data to help label distinct versions of the software.
poetry-dynamic-versioning
uses git
tags to help distinguish version data.
We also use the __init__.py
file as a place to persist the version data for occaissions where the git
history is unavailable or unwanted.
The following command is used to add poetry-dynamic-versioning
to Poetry for use with this project: poetry self add "poetry-dynamic-versioning[plugin]"
.
Versioning for the project is intended to align with GitHub Releases which provide git
tag capabilities.
Releases¶
We publish source code by using GitHub Releases available here. We publish a related Python package through the Python Packaging Index (PyPI) available here.
Release Publishing Process¶
Several manual and automated steps are involved with publishing coSMicQC releases. See below for an overview of how this works.
Notes about semantic version (semver) specifications:
coSMicQC version specifications are controlled through poetry-dynamic-versioning
which leverages dunamai
to create version data based on git tags and commits.
coSMicQC release git tags are automatically applied through GitHub Releases and related inferred changes from release-drafter
.
Open a pull request and use a repository label for
release-<semver release type>
to label the pull request for visibility withrelease-drafter
(for example, see coSMicQC#24 as a reference of a semver patch update).On merging the pull request for the release, a GitHub Actions workflow defined in
draft-release.yml
leveragingrelease-drafter
will draft a release for maintainers.The draft GitHub release will include a version tag based on the GitHub PR label applied and
release-drafter
.Make modifications as necessary to the draft GitHub release, then publish the release (the draft release does not normally need additional modifications).
On publishing the release, another GitHub Actions workflow defined in
publish-pypi.yml
will run to build and deploy the Python package to PyPI (utilizing the earlier modifiedpyproject.toml
semantic version reference for labeling the release).
Documentation¶
Documentation for this project is published using Sphinx with markdown and Jupyter notebook file compatibility provided by myst-parser and myst-nb to create a “documentation website” (also known as “docsite”). The docsite is hosted through GitHub Pages and deployed through automated GitHub Actions jobs which trigger on pushes to the main branch or the publishing of a new release on GitHub. Documentation is versioned as outlined earlier sections covering versioning details to help ensure users are able to understand each release independently of one another.
It can sometimes be useful to test documentation builds locally before proposing changes within a pull request. See below for some examples of how to build documentation locally.
# build single-version sphinx documentation
# (useful for troubleshooting potential issues)
poetry run sphinx-build docs/src docs/build
# build multi-version sphinx documentation
# (used in production)
poetry run sphinx-multiversion docs/src docs/build