Holiday questions :D

Hello,

I noticed from the recently closed PR that the build phase in the GitHub workflow was modified. I’ve reviewed the changes, tried to understand the overall process, and found a couple of inconsistencies that I’d like to clarify before providing an MR with some improvements. My intention is purely to understand the reasoning behind these changes and not to cast any negative light on the project… quite the opposite, I aim to help improve it.

What is the difference in meaning of build.yml, manual_doc.yml and build_and_docs_to_dev.yml ? because the list of environments is different: build.yml: 85 environments build_and_docs_to_dev.yml: ~88 environments. Some environments are present in one but not the other (e.g., esp32s3-atomS3U in build.yml but not in build_and_docs_to_dev.yml in the same location). The risk is that ‘Test’ builds test configurations that differ from those released. Additionally, Python and Node.js versions are inconsistent: build.yml: Python 3.13, Node 14.x, build_and_docs_to_dev.yml: Python 3.13, Node 16.x, manual_docs.yml: Python 3.11, Node 14.x

I would like to propose an MR with the following features: create reusable workflow for build matrix (eliminates duplicate lines), centralise environment list in a JSON or YAML file, Standardise Python/Node versions in global or similar variables, and Refactor documentation logic into a single reusable workflow… if I can do it this will be my little holiday present .

Happy holidays!

I’ve just submitted an improvement. The PR keeps full feature parity, with no new actions and no expected regressions. All details are documented in the branch README OpenMQTTGateway/.github/workflows/README.md at feature/workflow-reorganizzation · Odyno/OpenMQTTGateway · GitHub

What I changed:

  • Unified build logic into reusable workflows

  • Added environments.json to centralize PlatformIO environments

  • Updated main workflows to use the new shared structure

  • Improved the release workflow and integrated docs generation

  • Created a reusable linting workflow

  • Simplified the manual docs workflow

  • Updated workflow dependencies and versions

Refactor GitHub Actions workflows for build, documentation, and linting by Odyno · Pull Request #2260 · 1technophile/OpenMQTTGateway · GitHub

and I’ve extended the previous Workflow Reorganization with new security features and smarter build logic. Full details are in the branch README OpenMQTTGateway/.github/workflows/README.md at feature/sec-workflow · Odyno/OpenMQTTGateway · GitHub.

Security updates

  • SBOM generation (CycloneDX + SPDX) for all firmware

  • SBOM uploaded with artifacts

  • Trivy vulnerability scanning with GitHub Security integration

Improvements

  • Selective builds:

    • Anonymous branches → 15 key environments

    • Notable branches / PRs → full builds

  • Linting merged into the main build task

You can compare the updated workflow docs between the two branch READMEs.