Skip to content

Automatic or Manual Firmware Compilation

Build train

Generates kernels at code push if the code, patches or config were changed in any way. It is also triggered via cron in the middle of Central European Time (CET) night.

Build

The build train is executed only if there are changed kernels. When this happens, it also generates armbian-firmware, desktop and u-boot packages. If the build succeeds it pushes packages to the package repository and increments trunk build version.

  • generates all changed kernels,
  • generate all boot loaders for all supported hardware,
  • generate desktop pacakages,
  • generates armbian-firmware, armbian-zsh, armbian-config.

You can change source repository and you can change destination package repository to https://beta.armbian.com (default) or https://apt.armbian.com

Manual Executing rights: Armbian project member

Automatic or Manual Images Compilation

Build Images

Build

Automatically generates all beta images if firmware compilation was succesfull. It only rebuilds images if changes were made.

  • can build release candidate or stable images,
  • can select build source repository,
  • can choose packages source repository apt.armbian.com or beta.armbian.com,
  • can build images for one or more boards with targets defined in this configuration.

Manual executing rights: Armbian release manager

Smoke tests on hardware devices

Smoke testing is preliminary testing to reveal simple failures severe enough to, for example, reject a prospective software release. Our test case is constructed of three steps:

Smoke

  • powering test equipment, consistent from several network switches, power supplies and dozens of hardware platforms
  • running upgrade, reboot, repository switch, reboot, … tests in parallel
  • uploading a test report as build artefact following by powering the devices off.

Manual Executing rights: Armbian project member

Automatic Pull Requests Labeler

Automatic Labeler

Automatically label new pull request based on the paths of files which are being changed. Configuration file can be found in:

Text Only
1
    .github/labeler.yml

Manual Pull Requests rebase

Automatic Rebase

Pull most recent code from master branch and put your work on top of your pull request.

How to use it? Simply comment

Text Only
1
   /rebase

to trigger the action.

Automatic or Manual Desktops Test Builds

Build All Desktops

Generates all desktops for arm64 and x86 arhitecture to verify if they build correctly. Build is triggered every day, manually (by any member of Armbian project) or in pull requests if label “Desktop” is set. Aim of this test case is to find out if there are troubles in packages relations.

  • releases: bullseye, sid, jammy, focal,
  • desktop environments: xfce, gnome, mate, cinnamon, budgie, kde-plasma,
  • builds are not using cached rootfs to force packages assembly,
  • included applications paths are “3dsupport browsers”,
  • builds are done with Docker image on public runners.

Automatic Kernel Build at Pull Requests

Generates kernels at Pull Requests if their code, patches or config was changed. Build starts when label of Pull Request is set to “Ready”

Integrity testings

This action tests package integrity from all stable images at download section.

Manual Executing rights: Armbian project member

Forked Helper

  • Run repository dispatch to default fork branch
  • Dispatch event on forked repostitory

Lint On Scripts

Run ShellCheck on all scripts and generates report as a build artefact. Since our scripts are full of shellcheck problems we don’t stop this action on errors. Not yet. For now, a report is generated. One has to download artefacts to see where the problems are.

Linting is run automatically on every push, including pull requests.

Scorecards Security Scan

Scorecards is an automated tool that assesses a number of important heuristics (“checks”) associated with software security and assigns each check a score of 0-10. You can use these scores to understand specific areas to improve in order to strengthen the security posture of your project. You can also assess the risks that dependencies introduce, and make informed decisions about accepting these risks, evaluating alternative solutions, or working with the maintainers to make improvements.

https://github.com/ossf/scorecard#what-is-scorecards

Back to top