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.
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,
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](https://github.com/armbian/build/blob/master/config/targets.conf).
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:

- powering test equipment, consistent from several network switches, power supplies and dozens of hardware platforms
[](https://github.com/armbian/build/actions/workflows/build-all-desktops.yml)
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](https://github.com/orgs/armbian/people)) 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.
Run [ShellCheck](https://github.com/koalaman/shellcheck) on changed shell scripts and report problems within. Since our scripts are full of shellcheck problems we don't block merging on those errors. Not yet.
Linting is run automatically on pull requests change.
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.