Use GitHub Actions for CI #236
Conversation
On every push and pull request, the files of the repository will be checked for commonly misspelled words using codespell. The workflow is also run weekly in order to catch new misspelled word detections that result from updates to the codespell dictionary. In the event of a false positive, add the word in all lower case to megaavr/extras/ci/codespell-ignore-words-list.txt
This workflow checks for common issues with the structure of the platform bundled libraries.
This workflow checks for common issues with the library.properties files of the platform bundled libraries.
This workflow checks for common problems with the keywords.txt files of the platform bundled libraries.
The Arduino IDE requires the use of a single true tab separator between the keyword name and identifier. When spaces are used rather than a true tab, the keyword is not highlighted. Reference: https://arduino.github.io/arduino-cli/latest/library-specification/#keywordstxt-format
Some low quality text editors may use this encoding by default. The invisible BOM character added to the first line can cause confusing errors.
There is no reason for a file to ever start with a blank line, so adding one would only pollute the diff.
The code uses spaces for indentation.
Example sketches of all bundled libraries are compiled for all boards of the platform.
On every push, change in memory usage is calculated and displayed in the workflow build log. A JSON format file containing this information as well as other data on the compilations is saved as a workflow log. The memory usage change report will be commented to the pull request thread.
…warning count The compiler warning count delta will be displayed in the workflow build log and in the workflow artifact files.
|
Wow, this is just fantastic. Of course, as it happens, I'm about to need to redo the board selection part.... But it's already found several bugs, lol... |
|
The logic failures are a bug, for example. |
|
(I am completely reorganizing the board options to get rid of all the (available only on XYZ) type caveats in the tools submenus) |
|
But this gives me all the structure I need in order to adapt it to future changes. I like how it's integrated with github now. |
I'm very glad if you find it to be useful!
Nice! I couldn't even begin to figure that stuff out, so figured I'd leave it to the expert.
The uniformity between the boards made this platform really work well with the GitHub Actions matrix job feature. I haven't been able to do anything like that in the other CI configurations I've set up. It's interesting to compare compile-examples.yml with my proposed .travis.yml from the previous PR:
Especially considering there were far fewer supported parts at that time. Even though the requirements of this boards platform caused compile-examples.yml to be fairly complex, I think the modular, programmatic approach I took this time will be more easy to maintain than the "wall of text" approach of my .travis.yml.
I was reluctant at first to transition from Travis CI to GitHub Actions because it meant throwing away years of experience with the Travis CI framework and learning something new from scratch, but it actually went pretty easily and I'm glad now that I did it. The formalized "actions" system is really great. You could do the same sort of thing in Travis CI of course. You could consider my per1234/arduino-ci-script as a "proto-action". But I never saw the open source community developing the huge number of tools targeted to Travis CI like I do now with GitHub Actions. Pretty much anything you want to do, just do a search for "github actions ..." and someone has made an action for it! You can combine the available actions in interesting ways to do complex things with farily minimal workflows. |
|
Realized there was an unforseen issue with my major boards.txt refactor.... deferring, and possibly canceling.... |
Important:
The Compile Examples workflow is not passing. Some of the Logic library examples are not compiling. The reason is because I don't have the understanding about this subject to know what the requirements of the sketches are and what errors are expected vs. potential bugs. However, the important thing is I have put in place a framework that allows you to configure the CI system to handle this sort of sketch/board compatibility issue. The existing workflow configuration should provide enough of a reference to adjust it according to your needs.
You can see the workflow run here: https://github.com/per1234/megaTinyCore/actions/runs/287577312
Because it was added after I started working on the project, I didn't add the USERSIG library to the Compile Examples workflow. It should be simple enough to add those examples in to the framework I've established.
I haven't set the Compile Sketches workflow up to test for the Xplained boards. I have invested all the time I have for volunteer work on the project so will be unable to add those. It should be relatively easy to expand on what I have established here to add those boards. The one thing you have to watch out for is that GitHub Actions has a 256 jobs per workflow maximum limit and those matrix jobs can multiply to large numbers very easily. I initially set the workflow up to test for more combinations of the custom board actions and it ended up being thousands of jobs.
I'm not going to be able to spend much more time working on this project, however, I am very interested in any bug reports or feature requests for the arduino/compile-sketches and arduino/report-size-deltas actions I used for the compilation tests. These actions are the replacements for the compilation testing functionality of my per1234/arduino-ci-script project.
Fixes #36
Closes #43