Add CI workflows for compilation testing, spell check, and formatting check #1
Conversation
This workflow compiles all compatible built-in example sketches for one board of each distinct type from the latest release of each active official boards platform using the latest version of Arduino CLI. The Starter Kit sketches are only compiled for the Uno because that is the board those sketches are designed to be used with. This workflow is triggered on: - pull request (to validate PRs) - push (to validate commits when preparing to submit a PR) - schedule (to check for breakage caused by changes to boards platforms and libraries - manual trigger of the workflow by either the GitHub web interface or the GitHub API
This workflow uses codespell to check all files in the repository for commonly misspelled words. The "blocklist" strategy used by codespell leads to a minimal number of false positives at the cost of an increased likelihood of false negatives when compared to the more common "smart allowlist" strategy used by spell checkers. In the event of a false positive, add the problematic word, in all lower case (regardless of the case of the occurence of the word in the repository) to extras/codespell-ignore-words-list.txt. The workflow is triggered: - On pull requests - On push (to validate commits in preparation for a PR) - On weekly schedule (to check for new misspelled word detections as a result of updates to the codespell dictionary)
…e formatting style The existing examples_formatter.conf configuration for Artistic Style is used. Although this configuration does add some additional formatting rules, it will most often be possible to achieve compliance simply by using the IDE's Auto Format feature. The repository also contains an examples_formatter.sh script that will automatically format the examples according to the configuration.
I verified that leading spaces are supported in Max/MSP patches.
It was necessary to run the formatter script again after adding all sketch file extensions to get full formatting of all sketch files.
This is only required because the repository is currently private. This commit can be reverted once the repository is made public.
|
PR approved but I have a question nonetheless, why are we using |
I chose it because astyle is the tool used by the Arduino IDE's Tools > Auto Format feature and also used by the manually run formatter script. Although the formatter configuration defined by examples_formatter.conf does add a few additional things, my primary goal is for the examples to always be compliant with the formatting style established by the default auto format settings. It seems like this can most easily be achieved by using the same formatter tool for the check. My concern with using a different formatter tool is that there might be some subtle differences in the formatting. I haven't investigated this at all though. I'm certainly open minded about other tools, but I'll ask you the opposite question: Why not use astyle? |
|
Just a matter of personal preference in this case, I've always used If it's already used by the Arduino IDE I'm fine with it. |
|
@silvanocerza I remember a while back (actually one of my first interactions with @per1234 ) I was trying to get |
These GitHub Actions workflows will:
NOTE:
The failure of the Compile Examples workflow run is due to legitimate compilation errors.
These should be resolved by either:
Or
That work is out of scope for this PR.
reference to 'SPISettings' is ambiguousreference to 'SPISettings' is ambiguousundefined reference to 'pulseIn'reference to 'SPISettings' is ambiguous'tone' was not declared in this scope