Implement KiBot Automation

[pasrom]

This pull request introduces an automated KiBot workflow and updates the KiCad PCB and schematic files (as outlined in https://github.com/LibreSolar/bms-c1/pull/46#issuecomment-1848353134). The changes are intended to streamline the design verification process and ensure consistent output generation.

Key Changes:

1. KiBot Workflow Integration:

   • Added a new GitHub Actions workflow kibot.yml to automate the KiBot process.
   • This workflow triggers on push or pull requests that modify KiCad schematic (*.kicad_sch) or PCB (*.kicad_pcb) files, and also includes a repository_dispatch event for manual triggering.

2. KiBot Configuration:

   • Introduced config.kibot.yaml, a comprehensive KiBot configuration file.
   • This configuration covers various outputs including BOM, Gerber files, PCB diff, datasheets downloading, and more, enhancing the PCB design and review process.

3. KiCad File Modifications:

   • Minor updates to bms-c1.kicad_pcb and related schematic files.
   • Adjustments include changes to part remarks and reference designators.

4. .gitignore Updates:

   • Updated .gitignore to exclude KiBot output directories (output and .cache) from version control.

Benefits:

• Automated validation and artifact generation for PCB designs.
• Easier tracking and review of changes through automated diffs.
• Centralized and version-controlled configuration for design outputs.

Additional Notes:

• The KiBot configuration is based on a standard template and adjusted for the project needs.
• Future enhancements can be made to the workflow and KiBot configurations as needed.

[pasrom]

What isn't fully clear to me, is how we would use/consume the KiBot output. Right now, the GHA "just" uploads build artefacts, but they aren't really easy to discover for an average user.

Perhaps a method similar to this example (see the result here; similar output is generated by this commit) could be implemented and then incorporated into the documentation?

For some of the KiBot functionality, it makes sense to run it on every commit. Like the linting and DRC/ERC error checks.

However, others, like the generation of production files mau requires more effort. If we were to create releases for this all the tagged versions of the BMS, we could have KiBot automatically generate production files and attach them to a given release.

Do you suggest running the preflight tests on every commit, and reserving other time-intensive tasks in the build process for only when a new version tag is created?

[martinjaeger]

Thanks @pasrom also from my side for getting the ball rolling.

I think I agree with @dmohns that the results of the KiBot run should be more easily accessible. In the long term it would be nice to have the following:

PRs

Generate diff and automatically create a comment which contains the diffs (probably as PDF). If the PR is updated later on, the comment should also be updated (instead of creating a new comment). I've seen similar behavior for code coverage reports in software repos.

Commits added to main (after PR merge)

Generate production files and push them into gh-pages branch, so that they are available under https://libre.solar/bms-c1/ in addition to the manual and the interactive BOM.

Releases

Generate all production files and upload them as release artifacts (instead of the current approach where I create the files manually and add them to the build folder).

Any idea how generating a comment with the diff files could work and if it would be possible to include it in this PR?

[dmohns]

I think we actually have a few different tasks here. Maybe we can split them into multiple PR's to make things more manageable. In fact, I think we should create separate Github actions YAML's for each of the below

---

Running lint and checks on every commit

Covers the initial run of KiBot. This just checks for errors and warnings. I think by default non of the warnings actually make the run exit with an error code, so all checks will always go green. We can tweaks this later according to https://github.com/INTI-CMNB/KiBot/blob/master/README.md#filtering-drc-and-erc-errors

Running diff tools on PR commits

All steps of type diff. We would have to figure out a way to have Github Actions comment on the PR. There is some pre-built community actions, see https://github.com/marketplace?category=&type=actions&verification=&query=pr+comment

Generate documentation files on every commit in main

ibom, all types of renders, maybe PDF outputs. KiBot allow beautiful renders with Blender (but this will probably something for future again). We also need to check, how this can be integrated with Github Pages.

Generate production files as release artefacts

gerbers, drill files, etc... Before we can reasonably do this, we might need to change the release workflow to use Github Releases.

---

WDYT: Let's use this PR to work on the first "Running lint and checks on every commit", then create separate Issues and PR's of the other three and discuss the details for individual tasks there?

[pasrom]

I agree with the approach of dividing the tasks into multiple PRs for greater clarity and manageability. I have developed solutions for the following two tasks:

Running Lint and Checks on Every Commit

For reference, see my commit here: https://github.com/pasrom/bms-c1/commit/74e3e5c1cba63a7620a219abf1c1152eb48fa168

Running Diff Tools on PR Commits

I have implemented the following steps for this task:

1. actions/upload-artifact@v4 to upload and retrieve the artifact IDs.
2. peter-evans/find-comment@v2 for identifying any existing commit messages.
3. peter-evans/create-or-update-comment@v3 to add comments with the schematic and PCB PDFs to the PR.

A PoC is available here: https://github.com/pasrom/bms-c1/pull/1) (Note: KiBot diff-generation not yet included, but should be straightforward).

Next Steps

I will update this PR with the lint and checks task and create another PR for the diff tools task. Does this align with your views, @martinjaeger and @dmohns?

[dmohns]

Next Steps

I will update this PR with the lint and checks task and create another PR for the diff tools task. Does this align with your views, @martinjaeger and @dmohns?

Sounds good to me 👍

[martinjaeger]

The PoC in your example PR looks really great. And I'm more than happy with the approach.

Will do a final check, probably tomorrow, before merging this PR.