docs: fix typos

Found via `codespell -L nd`

Author: kianmeng

.github/workflows/generate.yaml

@@ -68,7 +68,7 @@ jobs:
           tox -e "py310{-sdist, -wheel, -dev}"
           tox -e coverage
 
-      ## Verify Development Scripts operate as intented out of the box
+      ## Verify Development Scripts operate as intended out of the box
       - name: 'Ruff: Fast Python Linter -> PASS'
         run: |
           cd gen/biskotaki

.github/workflows/quick-docs.yaml

@@ -87,7 +87,7 @@ jobs:
 
       - run: git fetch
       - run: git log --graph --decorate --color --all --stat
-      - run: echo "Expect above log to proove local and origin empemeral-doc-updates branches are deleted"
+      - run: echo "Expect above log to prove local and origin empemeral-doc-updates branches are deleted"
 
       ### WORKFLOW No 2 - EMBEDDED ###
 

.github/workflows/test.yaml

@@ -44,7 +44,7 @@ env:
   # Override Docker Policy-dependent decision-making and
   # Accept any ALL (branch/build) to Publish to Dockerhub
   # if true, it will push image and ignore DOCKER_JOB_POLICY
-  ALWAYS_BUILD_N_PUBLSIH_DOCKER: "false"
+  ALWAYS_BUILD_N_PUBLISH_DOCKER: "false"
 
   DOCKER_JOB_POLICY: "CDeployment"
   # - CDeployment : Builds and Publishes only if Tests ran and passed
@@ -86,7 +86,7 @@ jobs:
           echo "PUBLISH_ON_PYPI=$PUBLISH_ON_PYPI" >> $GITHUB_OUTPUT
       ## Docker - Pipeline Settings ##
       - id: derive_docker_policy
-        run: echo "POL=${{ (env.DOCKER_JOB_ON != 'true' && '0') || (env.ALWAYS_BUILD_N_PUBLSIH_DOCKER == 'true' && '1') || (env.DOCKER_JOB_POLICY == 'CDeployment' && '2') || (env.DOCKER_JOB_POLICY == 'CDelivery' && '3') }}" >> $GITHUB_OUTPUT
+        run: echo "POL=${{ (env.DOCKER_JOB_ON != 'true' && '0') || (env.ALWAYS_BUILD_N_PUBLISH_DOCKER == 'true' && '1') || (env.DOCKER_JOB_POLICY == 'CDeployment' && '2') || (env.DOCKER_JOB_POLICY == 'CDelivery' && '3') }}" >> $GITHUB_OUTPUT
       ## Static Code Analysis - Pipeline Settings ##
       - id: derive_sqa_policy
         run: echo "POL=${{ (env.RUN_LINT_CHECKS != 'true' && '0') || (env.ALWAYS_LINT == 'true' && '1') || env.LINT_JOB_POLICY }}" >> $GITHUB_OUTPUT

.pylintrc

@@ -60,7 +60,7 @@ confidence=
 # can either give multiple identifiers separated by comma (,) or put this
 # option multiple times (only on the command line, not in the configuration
 # file where it should appear only once). You can also use "--disable=all" to
-# disable everything first and then reenable specific checks. For example, if
+# disable everything first and then re-enable specific checks. For example, if
 # you want to run only the similarities checker, you can use "--disable=all
 # --enable=similarities". If you want to run only the classes checker, but have
 # no Warning level messages displayed, use "--disable=all --enable=classes

CHANGELOG.rst

@@ -21,10 +21,10 @@ out-of-the-box produced by the `Generator` as part of the **CI/CD Pipeline**
 configuration YAML files, to be **Configurable by Policy**.
 
 *Design* a **High-Level** interface, for *configuring the CI/CD Behaviour*, allowing:
-- seemless switching between **Policies**, on a per-Job level
+- seamless switching between **Policies**, on a per-Job level
 - Easy **Override** to `"shutdown" Job"`, ie to *prevent upload*, by-passing `decision-making`
 - Easy **Override** to `"force Job"`, ie for *quick trial*, by-passing `decision-making`
- governing desicion-making, on the Workflows/Jobs.
+ governing decision-making, on the Workflows/Jobs.
 
 A **Policy** governs how a Job behaves (ie if it should trigger), and each
 one yiels a *distinct* behaviour.
@@ -65,7 +65,7 @@ feature
 """""""
 - introduce `Ruff`, Fast Python Linter, in updated `Developer's Tool chain <https://github.com/boromir674/biskotaki/tree/auto-generated?tab=readme-ov-file#development>`_
 - run `Ruff` against code, as part of the Tools included in the `Static Code Analysis` CI Workflow, produced by the **Generator's** Template
-- run legacy `Pylint` agaist code, in dedicated Job, for easier potential retirement
+- run legacy `Pylint` against code, in dedicated Job, for easier potential retirement
 - make Template Code pass Ruff Checks/Evaluations
 - add `Ruff`, `tox -e ruff`, as available `tox command`` for fast `Static Code Check`
 
@@ -150,7 +150,7 @@ Changes
 ci
 ""
 - remove unused workflow
-- fix workflow syntax due to merge confict resolution artifacts
+- fix workflow syntax due to merge conflict resolution artifacts
 
 
 1.8.1 (2023-12-15)
@@ -191,7 +191,7 @@ test
 - verify `No Regression` of Generator, with exhaustive comparison of Runtime result to `Gold Standard`
 - test `Gold Standard` passes `tox -e lint`
 - ignore Tests inside Snapshots, during `Test Discovery` of Pytest
-- verify `User Config` backwords compatibility, with regard to new `Docs` Generator Feature
+- verify `User Config` backwards compatibility, with regard to new `Docs` Generator Feature
 - test default gen behaviour related to Docs, is same as before adding mkdocs option
 - yaml validation and required/expected workflow vars checks
 
@@ -368,7 +368,7 @@ Changes
 
 test
 """"
-- manually covert gitpython outputted string paths into Path instances
+- manually convert gitpython outputted string paths into Path instances
 - use Path from pathlib instead of the os.path module
 
 refactor
@@ -379,7 +379,7 @@ refactor
 
 ci
 ""
-- excplicitly use bash as the shell for some job steps
+- explicitly use bash as the shell for some job steps
 
 
 1.6.0 (2022-06-28)
@@ -407,7 +407,7 @@ Changes
 feature
 """""""
 - add 'project_type' Variable allowing for 'module', 'module+cli' or 'pytest-plugin' Projects
-- conditionaly populate 'test' dependencies, ie based on whether there is a cli entrypoint
+- conditionally populate 'test' dependencies, ie based on whether there is a cli entrypoint
 
 
 1.5.2 (2022-06-22)
@@ -551,7 +551,7 @@ to support and be tested on.
 The generator then creates the Test Matrix in the CI config file, which factors in the
 Python Interpreter versions supplied by the user. 
 
-Consistent with the currect behaviour of the cli, passing the '--no-input' flag,
+Consistent with the current behaviour of the cli, passing the '--no-input' flag,
 instructs the Generator to try find the selected interpreters in a config yaml file,
 if given, or else to use the information in the cookiecutter.json.
 
@@ -565,7 +565,7 @@ Development
 -----------
 
 All tox environments related to 'Linting' now all do by default a 'check'.
-Doing a 'check' means returning a 0 as exit code in case the check is successfull
+Doing a 'check' means returning a 0 as exit code in case the check is successful
 and it is suitable for local and remote running on a CI server.
 
 The aforementioned environments are 'lint', 'black', 'isort':
@@ -606,7 +606,7 @@ build
 1.2.1 (2022-05-27)
 ==================
 
-Compeltely migrate away from *setup.cfg*.
+Completely migrate away from *setup.cfg*.
 Add Issue Templates, as markdown files, to help create well documented Issues on github.
 
 Changes

CONTRIBUTING.md

@@ -19,7 +19,7 @@ You can contribute in many ways:
 
 Report bugs at [https://github.com/boromir674/cookiecutter-python-package/issues](https://github.com/boromir674/cookiecutter-python-package/issues).
 
-Stmbling upon a Bug means encountering different behaviour than the expected/advertised one. When you are reporting a bug, please include the following infromation by filling in [the template](https://github.com/boromir674/cookiecutter-python-package/.github/blob/master/.github/ISSUE_TEMPLATE/bug_report.md).
+Stmbling upon a Bug means encountering different behaviour than the expected/advertised one. When you are reporting a bug, please include the following information by filling in [the template](https://github.com/boromir674/cookiecutter-python-package/.github/blob/master/.github/ISSUE_TEMPLATE/bug_report.md).
 
 * Your operating system name and version.
 * Any details about your local setup that might be helpful in troubleshooting.
@@ -90,7 +90,7 @@ git checkout -b name-of-your-bugfix-or-feature
 
 Now you can make your changes locally.
 
-Probably, you should start by writting test case(s) and then the production code.
+Probably, you should start by writing test case(s) and then the production code.
 
 
 1. When you're done making changes, check that your changes pass the tests locally.

Dockerfile

@@ -3,7 +3,7 @@ FROM python:3.9.16-slim-bullseye as builder
 # for inspiration
 COPY poetry.lock pyproject.toml ./
 
-# Envrironment Configuration
+# Environment Configuration
 ## See https://github.com/alejandro-angulo/poetry/blob/master/docs/configuration.md
 # Determine where to install poetry
 ENV POETRY_HOME=/opt/poetry

docs/conf.py

@@ -21,7 +21,7 @@
 
 sys.path.insert(0, os.path.abspath('../src/cookiecutter_python'))
 
-# Please use the Sphinx format for writting docstrings (other fornats include Google and Numpy which require the 'napoleon' extension). 
+# Please use the Sphinx format for writing docstrings (other formats include Google and Numpy which require the 'napoleon' extension). 
 
 # -- Project information -----------------------------------------------------
 

docs/contents/10_introduction.rst

@@ -6,7 +6,7 @@ Introduction
 | The Template is implemented as a *cookiecutter* and it is available both as source code and as a Python Package in itself.
 
 | Goal of this project is to automate the process of creating a new Python Package, by providing the user with a "bootstrap" method,
-| to quickly set up all the *support* files required to seemlessly build and publish the package on pypi.org (the official Python Pcakge Index public server).
+| to quickly set up all the *support* files required to seamlessly build and publish the package on pypi.org (the official Python Pcakge Index public server).
 | Additionally, it instruments a basic **Test Suite**, multiple **Commands**, as well as a **CI** pipeline, with parallel execution of the *build matrix*, running on *Github Actions*.
 
 | This documentation aims to help people understand what are the features of the library and how they can use

docs/contents/30_usage/index.rst

@@ -24,7 +24,7 @@ Generated Python Project Use Cases
 .. include:: use_cases.rst
 
 
-.. Reminders on how to be consistent accross sectoining and their semantics
+.. Reminders on how to be consistent across sectoining and their semantics
     ========
     DocTitle
     ========