Skip to content

Continuous integration

Sven Roederer edited this page May 4, 2021 · 10 revisions

Continuous integration was setup for the firmware in the middle on 2014. For this deployment the Buildbot-Framework was choosen.

Since October 2020 the Repo uses the GithubAction "build Firmware" for PRs and merges.

Review of Solutions and Frameworks

Buildbot

The initial deployment was done in 2014 and is managed via the buildbot-Repo. In 2020 there was a major redeployment with updated software and a new VM. The build-process is triggered via a WebHook of the firmware-repository.

Advantages

  • independent infrastructure, self hosted by community
  • full customizable

Disadvantages

  • changes of the firmware buildsystem must be coordinated with the buildbot-admins
  • the community needs to provide the workers
  • maintenance of hardware and OS

Statistics

  • build-times (OpenWrt and fonal Firmwareimages): up to 3,5 hours (depending on worker and "V"-logging flag)
  • uploading (Firmwares, SDK, Images, *.ipkg): > 60 minutes (depending on worker)

TravisCI

In May 2020 @SvenRoederer did some tests with alternative CI solutions and gave TravisCI a test. TravisCI is a hosted service that is free of charge for OpenSource projects. At this time Travis offered worker-VMs with 2 CPUs and allowed up to 5 jobs in parallel.

The Work that was done is preserved in https://github.com/freifunk-berlin/firmware/files/4685107/TravisCI.zip, which is linked to issue https://github.com/freifunk-berlin/firmware/issues/804, for the case of additional research.

Advantages

  • configuration via .travis.yml in root-folder of project, which allows quick changes

Disadvantages

  • building the firmware with V=s option, creates more than 4MB output, which exceeds the limit.
  • building with normal verbosity triggers the "output timeout" of 10 minutes
    • this can be worked around by using a "keep-alive" script
    • extending the limit with the travis_wait command
  • the global job-time limit of 50 minutes is to small, to build OpenWrt-SDK and OpenWrt-Imagebuilder on a 2 CPU host

CircleCI

Was just checked for short, but it was hard to find, if there is a "free for OpenSource" option.

Jenkins

This is an other framework, like buildbot, but seems not to be hosted. For this reason it was not checked further at the time of writing. the same advantages and disadvantages like buildbot apply, maybe in a different flavor.

GithubActions

In the end of 2019 GitHub opened its GithubActions and made it free for OpenSource projects (free for public repositories). Like TravisCI the workers are 2CPU VMs, but up to 20 parallel jobs are supported. GitHub also offers an integrated solution to upload build-artifacts (logs, binaries). The hardware is provided by Microsoft Azure, at the time of writing (May 2020) these are Dv2 and DSv2-series instances.

Advantages

  • direct relation between commit and build, all is linked on the web
  • configuration iwth YML-files in the .github/workflow/ folder, similar to TravisCI
  • hosted workers and private workers

Disadvantages

Statistics

  • building the required OpenWrt binaries (Imagebuilder, SDK and *.ipkg) takes less than 2h
  • uploading the binaries (as build-artifacts to GitHub) is done in 4 minutes
  • uploading the full build-logs takes less than 1 minute