-
Notifications
You must be signed in to change notification settings - Fork 0
Automations and quality controls
Or ... What parts are automated?
For the modules we 'mostly' re-use what is applicable for HA-core, though, as they are (actually) stand-alone modules it's minimal use. For the beta repositories we (from time to time) rework things into our repo's. This applies to the workflows (see Actions below), pyproject.toml and mypy.ini files.
For the module; if you correctly updated the version in pyproject.toml than the process will try to create a new version on (test)-PyPi each time the action is run (see further down this comment about actions). It will always build a version and try to upload it, just silently fail if the version already exists. The same goes for merging of PRs, it will try and upload to production PyPi and silently fail. (I.e. we don't require updates of modules when build-tools are merged).
If you properly ran the setup-scripts, you will have pre-commit locally, meaning that whenever you commit files locally a bunch of things will run to ensure quality et such. As we can't enforce the pre-commit working locally, most of it is repeated on the GitHub side using Actions. These are configured through .github/workflows'. Just have a look and you'll see what's in the repositories for that. The betacomponent runs bothhassfest` (ensuring minimal quality gate for HA) and our own defined tests and checks.
What are all the 'renovate' things and why is there a 'Dependency Dashboard' issue in both repositories? We selected RenovateBot to do our chores, i.e. ensuring all kinds of dependencies are kept up to date. This runs fully automated for updating versions of things like pre-commit and the actions on Github and manual for python modules dependencies, reason being that we would like to be careful about just updating to any newer python dependency. Showcase would be aiohttp for our Smile counterpart where (for good reasons) HA-Core decided to wait for a proper release instead of following the latest and greatest. Renovate configuration is found in the main .github/ directory.
The 'generate release notes' from the checklist to create a new release is powered by the release configuration file in the .github/ directory.
Additionally we run the code through CodeCov, CodeFactor and SonarCloud all automatically to ensure quality and/or get a heads-up on improving our code skills.
As for the above, we are very aware of the 'complexity' of the code, we have accommodated multiple times in the past only to find diluting our code by creating separate functions. We currently accept complexity up to 80, though SonarCloud keeps it at 45 (hence we ignore it completely on SonarCloud for now). What is complexity.