Gluon site configuration to build firmware for Darmstadt.
master
:- matches Gluons
main
branch - basis for the next release
- firmware version: 3.1.x
- matches Gluons
v2023.2.x
- matches Gluon
v2023.2.x
branch - firmware version: 3.0.x
- matches Gluon
v2022.1.x
- matches Gluon
v2022.1.x
branch - firmware version: 2.6.x
- matches Gluon
v2021.1.x
:- matches Gluon
v2021.1.x
branch - firmware version: 2.4.x
- matches Gluon
v2020.2.x
:- matches Gluon
v2020.2.x
branch - firmware version: 2.2.x
- matches Gluon
v2020.1.x
:- matches Gluon
v2020.1.x
branch - firmware version: 2.0.x
- matches Gluon
v2019.1.x
:- matches Gluon
v2019.1.x
branch - firmware version: 1.8.x
- matches Gluon
v2018.2.x
:- matches Gluon
v2018.2.x
branch - firmware version: 1.6.x
- version 1.4.x was never released and collided with early 1.5.x release
- matches Gluon
v2018.1.x
:- matches Gluon
v2018.1.x
branch - firmware version 1.2.x
- matches Gluon
v2017.1.x
:- matches Gluon
v2017.1.x
branch - firmware version 1.0.x
- matches Gluon
Release | Gluon Commit |
---|---|
2.6.3 | v2022.1.4+ |
2.6.2 | v2022.1.3+ |
2.6.1 | v2022.1.1 |
2.6.0 | v2022.1 |
2.4.1 | v2021.1.1 |
2.4.0 | v2021.1 |
2.2.1 | v2020.2.3 |
2.2.0 | v2020.2 |
2.0.3 | v2020.1.3 |
2.0.2 | v2020.1.2 |
2.0.1 | v2020.1.1 |
2.0.0 | v2020.1 |
1.8.1 | v2019.1+8 |
1.8.0 | v2019.1 |
1.6.3 | v2018.2.3 |
1.6.2 | v2018.2.2 |
1.6.1 | v2018.2.1-19-gd3033163 |
1.6.0 | v2018.2.1-7-geed810aa |
1.4.0 | v2018.2.1 |
1.2.8 | v2018.1.4 |
1.2.7 | v2018.1.3 |
1.2.6 | v2018.1.1-4-g51b7928a |
1.2.5 | v2018.1.1-4-g51b7928a |
1.2.4 | v2018.1.1-4-g51b7928a |
1.2.3 | v2018.1.1 |
1.2.2 | v2018.1-11-g6a3d5554 |
1.2.1 | v2018.1-7-gea9a69f7 |
1.2 | v2018.1-5-g658f1ea4 |
Firmware is built using GitHub actions as a CI. For more information, see the
README.md
in the .github
subdirectory.
Builds are triggered by pushing a commit or tag to a branch. Both actions trigger a build cycle. Artifacts are available after the CI finished and are available on a per-target basis.
This repository contains a convenient script to sign a release created by this CI implementation.
The sign-release.sh
script located in the contrib
subfolder allows to obtain a signature for
a released firmware.
Usage: contrib/sign-release.sh <release-version> <private-key-path>
Example: contrib/sign-release.sh 2.0.0 /path/to/private-key.ecdsakey
Releases are triggered by pushing a tag to GitHub.
The resulting firmware is versioned by the tag, while the first -
in the tag name is replaced by a ~
character.
While Job artifacts expire eventually, artifacts from releases are preserved by creating a release on GitHub and uploading build-outputs as well as the generated manifest to it.