Automated compiling to perform CD/CI

timschneider

Hello,
i recently stumpled over some minor problems or wanted improvements with the RRF in different locations -> e.g. M200 SafeState on power down, heater power consumption / limiter, virtual endstops to map events like heaterfault to trigger#.g ... and while doing so I needed to compile the firmware to check quick fixed. Then I thought, that it would be usefull to automate the firmware creation for RRF with github actions, so that every push or merge request is automaticly checked against the current dev of the project and no one really needs to care about the dev environment anymore.
I'm currently on the Duet2 Ethernet, thats why I startet there and following the build instructions, one should start with the CoreNG, so did I. Following the variants/duetNG/build_gcc make file and logic, I copied that build logic to all dependencies to simplify maintainance.

I will upload all the modificaitions I did to my github today, but as a starting point the RRFLibraries in dev branch are already up.

https://github.com/timschneider/RRFLibraries/commit/2a6808c4c2c5ab9cbae5b86d237f57f1491634a4/checks?check_suite_id=399291871

So to conclude what I did:

changed the build scripts in variants/duetNG/build_gcc of CoreNG to perform like the Eclipse Build logic, e.g. with recursion and exlusion logic
copied that build scripts to every project (CoreNG, FreeRTOS, RRFLibraries, RepRapFirmware, DuetWiFiSocketServer (not yet))
adapted the build scripts according to the .cproject files of each project to behave similar to eclipse auto makefile generation
put the different dependencies in the github actions file (WIP)

This allows me to make a change to the code and get the newly build firmware right from github in an automated fashion.

what do you think about it? should we continue to work on that?

Tim

0

timschneider committed to timschneider/RRFLibraries

Update ccpp.yml

timschneider

Making some progress and while doing so, some example arised that showes how fragile the current process of firmware creation is.

According to the Build Instructions the different projects are on:

As at 08 January 2020, the latest RRF 3.x source code is on these branches:

RepRapFirmware: v3-dev
CoreNG: dev
FreeRTOS: master
RRFLibraries: dev
DuetWiFiSocketServer: master
CANlib : master

But the commit to RRFLibraries is breaking RepRapFirmware v3-dev because of the newly added Namespace of FreelistManager. Dunno if we should make a new branch for current dev or freeze the dependencies for a current version, but this is very easily shown in a CI process as the pipeline is not gonna make it through as shown in

btw. the example CI process is now up

CoreNG https://github.com/timschneider/CoreNG/actions
FreeRTOS https://github.com/timschneider/FreeRTOS/actions
RRFLibraries https://github.com/timschneider/RRFLibraries/actions
RepRapFirmware https://github.com/timschneider/RepRapFirmware/actions

Tim

gtj0

Good work!

The RRF v3-dev branch is no longer active and won't compile against RRFLibraries dev branch any more. The current RRF dev branch is 3.01-dev which will become the 3.1 release.

The inconsistent branch naming across the projects and the lack of tags that sync them all up is an issue I'm hoping @dc42 will get to one of these days.

timschneider

hey @gtj0 thanks for your reply, i did some work on the compiling of the duet as well, but i guess it is highly dependent upon @dc42 as the main developer of RRF.

Currently, I see the following challenges for the duet3d and RRF

with the rising number of duet derivates, it is getting more and more complex and complicated to test every one for each release and even the compiling is getting fiddly
the code coverage of test cases is, at least for me, not available
through the design of the project in different modules it is getting more and more complex for everyone else except dc42 to compile the firmware, as it is not clear which tag/branch/version is compatible to each other or which one is broken and probably why.

I see the following benefits in using an automated compiling and later testing process:

the community could support dc42 in creating testcase for parts of the software
the community could actively participate in the development without setting up an development environment
the compiling and testing for every derivate of the duet could be automated, like some boards are getting automaticly flashed with the last firmware from github and can perform some basic tests and return the results back

dunno if there is more.

Tim