Generate a deployment folder with all required files for easy PCBA

Generate a (secured) deployment folder with all required files for easy PCBA

• Installation
• Usage
• Example
• Contributing
  • Setup
  • Testing
  • Changelog
• Credits

[<PYTHON> -m] pip[3] install [--user] [--upgrade] pcba_helper

Create a login secured deployment folder from the KiCAD project at examples/KiCAD. The folder is named deploy and placed in the examples/KiCAD folder. The iBOM file is expected relative to the KiCAD project folder.

generate-deployments examples/KiCAD \
  --output examples/KiCAD/deploy \
  --ibom-file ibom/ibom.html \
  --username "John" \
  --password "secret" \
  -vvvv

The parameter --public is optional and creates pure HTML files which can be accessed without passing any login page, parameter values of username and password are ignored.

The docker-compose.yml generates the PDF from the KiCAD schematic, creates the deploy folder and fires up an Apache server with PHP at the fixed IP address 172.42.0.2.

[PUBLIC=1] docker compose up --build
docker compose down
[sudo] rm -rf examples/KiCAD/deploy

For active development you need to have poetry and pre-commit installed

python3 -m pip install --upgrade --user poetry pre-commit
git clone https://github.com/brainelectronics/pcba_helper.git
cd pcba_helper
pre-commit install
poetry install

# run all tests
poetry run coverage run -m pytest -v

# run only one specific tests
poetry run coverage run -m pytest -v -k "test_read_save"

Generate the coverage files with

python create_report_dirs.py
coverage html

The coverage report is placed at reports/coverage/html/index.html

The changelog format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

Please add a changelog snippet, see below, for every PR you contribute. The changes are categorised into:

• bugfixes fix an issue which can be used out of the box without any further changes required by the user. Be aware that in some cases bugfixes can be breaking changes.
• features is used to indicate a backwards compatible change providing improved or extended functionalitiy. This does, as bugfixes, in any case not require any changes by the user to keep the system running after upgrading.
• breaking creates a breaking, non backwards compatible change which requires the user to perform additional tasks, adopt his currently running code or in general can't be used as is anymore.

The scope of a change shall either be:

• internal if no new deployment is required for this change, like updates in the documentation for example
• external or all if this change affects the public API of this package or requires a new tag and deployment for any other reason

The changelog entry shall be short but meaningful and can of course contain links and references to other issues or PRs. New lines are only allowed for a new bulletpoint entry. Usage examples or other code snippets should be placed in the code documentation, README or the docs folder.

The name of the snippet shall be <ISSUE_ID.md>

[poetry run] changelog-generator \
    create .snippets/1.md

A big thank you to the creators and maintainers of SemVer.org for their documentation and regex example