Automated compiling to perform CD/CI



  • 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.

    c571f6a3-edd5-4af8-a48d-55d18ea10f59-grafik.png
    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



  • 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 dca450c7-1464-4ce2-9b16-c9df51a2c8e5-grafik.png

    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



  • 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.



  • 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


Log in to reply