Add documentation for infrastructure pages

docs/infrastructure/ci.rst

@@ -4,3 +4,39 @@
 
 CI/CD Pipeline
 ==============
+
+.. _build-ci:
+
+Build CI
+--------
+
+When code is pushed to the repository or a pull request is submitted, it will
+trigger a GitHub Actions run of the build CI, which can be found in
+``.github/workflows/push.yml``.  This build CI performs the following checks:
+
+- Code quality
+- Packaging build
+- Code testing
+- Code coverage
+
+You can read more about the code checks performed :doc:`here <codecheck>`
+
+CodeQL CI
+---------
+
+Similar to the build CI, a GitHub Actions performs a CodeQL check on the code
+whenever code is pushed to the repository or a pull request is submitted.
+Additionally, it runs this action daily to ensure best practices and look for
+issues as CodeQL is improved.
+
+.. _publish-ci:
+
+Publish CI
+----------
+
+When a release is made on GitHub for the project, it builds the project using
+the Python ``build`` package.  Before building, the publish CI pushes the
+release tag to the ``VERSION`` file.  The CI then uses ``build`` to generate
+both source and binary distributions of the project.  The CU then uploads
+these distributions to PyPI for download through tools such as ``pipx`` and
+``pip``.

docs/infrastructure/codecheck.rst

@@ -4,3 +4,33 @@
 
 Code Checking
 =============
+
+Code checks are performed using ``pre-commit``, which runs git pre-commit hooks on all files.
+
+If you are developing the ``circfirm`` codebase, you can install these hooks into git by
+runing ``pre-commit install``.
+
+You can manually perform a check of the code, which includes all of the items below, by
+running ``make check``.
+
+Linting & Formatting
+--------------------
+
+Linting and formatting are done using ``ruff`` pre-commit hooks, as well as some of
+the basic ``pre-commit`` ones provided by the project.
+
+You can manually run linting and formatting checks using ``make lint`` and ``make format``
+respectively.
+
+Secret Detection
+----------------
+
+Yelp's ``detect-secrets`` tool runs to try and prevent secrets from being accidentally
+committed and shared.
+
+Open Source Compliance
+----------------------
+
+The FSF's REUSE tool runs on the entire repository to make sure all files are properly
+labelled with an open source license and conform to REUSE standards, which makes it
+easier for other people to reuse any part of it.

docs/infrastructure/docs.rst

@@ -4,3 +4,11 @@
 
 Documentation
 =============
+
+Documentation is generated by Sphinx and a number of Sphinx extensions.
+
+This documentation is pushed with every ``git push`` using a repository
+webhook to ReadTheDocs so others can view it online.
+
+You can manually test building the documentation during development by
+running ``make docs``.

docs/infrastructure/tests.rst

@@ -4,3 +4,14 @@
 
 Testing & Code Coverage
 =======================
+
+The project contains test code for testing compliance of the tool with
+expected behavior.  Testing is done using coverage.py, which uses pytest
+to actually run the tests.  Coverage.py then analyzes the code that was
+run in both the source code and tests themselves to calculate the code
+coverage metric.
+
+In the :ref:`build CI <build-ci>` for pull requests, this code coverage
+metric is uploaded to Codecov, which then comments on the pull request
+to help identify whether additional tests are needed based on the
+changes.