-
Notifications
You must be signed in to change notification settings - Fork 21
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Create workflow to build and deploy balenaOS
Change-type: minor Signed-off-by: Kyle Harding <[email protected]>
- Loading branch information
1 parent
466d6ec
commit ab8da33
Showing
3 changed files
with
1,350 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
# balenaOS build + test + deploy reusable workflow | ||
|
||
The workflow is triggered on : | ||
|
||
1. PR events | ||
2. Creation of a new tagged version - this represents the PR being merged | ||
|
||
## On PR events | ||
|
||
1. OS is built | ||
2. draft hostapp release is pushed to balena cloud/staging. This is done by doing a `balena deploy` of the hostapp bundle to an app in balena cloud | ||
3. Nothing is deployed to s3 - there's no need currently | ||
4. leviathan tests are run , all 3 suites are in seperate matrix jobs | ||
|
||
## On new version tag | ||
|
||
1. The merge commit is fetched - and we check that the test jobs passed. We do this because some device types built might not have working test flows/be required to merge a PR | ||
2. OS is re built. This is because right now we can't guarantee that the artifacts from the PR build still exist | ||
3. finalised hostapp release is created given that tests from the merge commit passed. The presence of this finalised hostapp release is what lets the API say there is a new OS version available for that device type. Host os updates fetch the hostapp bundle from these apps | ||
4. artifacts are uploaded to s3 - including the balena OS image - when a user tries to download an OS image, this is where it comes from. The image maker constructs the url pointing to the s3 bucket based on device type, version etc when a user requests an OS image. There is no "direct" link between the hostapp and s3 bucket currently. | ||
5. release assets are attached to the hostapp using the file upload api - these include changelogs and licenses - in the case of device specific artifacts like custom rpi usboot `boot.img` they will also go here | ||
6. If its an esr release, esr tags are added. These tags are used by the api to signal the esr status - like next/sunset | ||
7. Tests are not re-run - they were already run on the PR / commit that was merged | ||
|
||
## Architecture diagram | ||
|
||
## Input defaults | ||
|
||
| | PR | New Tag | New Tag (esr) | Dispatch | | ||
|-------------------|-------|---------|---------------|----------| | ||
| deploy-s3 | false | true | true | | | ||
| deploy-hostapp | true | true | true | | | ||
| finalize-hostapp | false | true | true | | | ||
| check-merge-tests | false | true | true | | | ||
| run-tests | true | false | false | | | ||
| deploy-esr | false | false | true | | |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,120 @@ | ||
# This is an approximate example of a single Yocto device-type workflow | ||
# as it would exist in a device repo. | ||
|
||
# It will be duplicated across all device repos with only minor changes | ||
# to the inputs and the defaults. | ||
|
||
# TODO: We need a system to keep these inputs aligned across all device repos | ||
name: Generic x86_64 (GPT) | ||
|
||
on: | ||
# With these triggers the Yocto jobs will run | ||
# in parallel with the Flowzone jobs, which is fine for now | ||
# and allows us to better control what we want to test and when. | ||
# It is expected that Flowzone could fail, but yocto jobs will run. | ||
pull_request: | ||
types: [opened, synchronize, closed] | ||
branches: | ||
- "main" | ||
- "master" | ||
pull_request_target: | ||
types: [opened, synchronize, closed] | ||
branches: | ||
- "main" | ||
- "master" | ||
workflow_dispatch: | ||
# limited to 10 inputs for workflow dispatch | ||
inputs: | ||
environment: | ||
description: The GitHub Environment to use for the job(s) (production, staging, etc.) | ||
required: true | ||
type: choice | ||
options: | ||
- staging | ||
- production | ||
deploy-s3: | ||
description: Whether to deploy images to S3 | ||
required: false | ||
type: boolean | ||
default: true | ||
deploy-hostapp: | ||
description: Whether to deploy a hostApp container image to a balena environment | ||
required: false | ||
type: boolean | ||
default: true | ||
finalize-hostapp: | ||
description: Whether to finalize a hostApp container image to a balena environment | ||
required: false | ||
type: boolean | ||
default: false | ||
deploy-esr: | ||
description: Enable to deploy ESR | ||
required: false | ||
type: boolean | ||
default: false | ||
deploy-ami: | ||
description: Whether to deploy an AMI to AWS | ||
required: false | ||
type: boolean | ||
default: false | ||
sign-image: | ||
description: Whether to sign image for secure boot | ||
required: false | ||
type: boolean | ||
default: false | ||
run-tests: | ||
description: Whether to run tests | ||
required: false | ||
type: boolean | ||
default: false | ||
os-dev: | ||
description: Enable OS development features | ||
required: false | ||
type: boolean | ||
default: false | ||
|
||
jobs: | ||
yocto: | ||
name: Yocto | ||
uses: ./.github/workflows/yocto-build-deploy.yml | ||
secrets: inherit | ||
with: | ||
# runs-on: '[ "ubuntu-latest" ]' | ||
# On device repos we need to hardcode: machine | ||
# On -some- device repos, we need to also hardcode (defaults will work otherwise): | ||
# for private device types: test-environment | ||
# for device types we use virtualised testing for: test-workers | ||
machine: generic-amd64 | ||
test-environment: bm.balena-dev.com | ||
test-workers: qemu | ||
# Allow overriding these inputs for manual triggers | ||
environment: ${{ inputs.environment || 'balena-staging.com' }} | ||
sign-image: ${{ inputs.sign-image || false }} | ||
os-dev: ${{ inputs.os-dev || false }} | ||
deploy-s3: ${{ inputs.deploy-s3 || true }} | ||
deploy-hostapp: ${{ inputs.deploy-hostapp || true }} | ||
deploy-ami: ${{ inputs.deploy-ami || false }} | ||
deploy-esr: ${{ inputs.deploy-esr || false }} | ||
finalize-hostapp: ${{ inputs.finalize-hostapp || false }} | ||
run-tests: ${{ inputs.run-tests || true }} | ||
# Below inputs are not required on device repos as the defaults should be used | ||
device-repo: balena-os/balena-generic | ||
device-repo-ref: master | ||
|
||
# environment: staging | ||
# device-repo: balena-os/balena-raspberrypi | ||
# device-repo-ref: master | ||
# yocto-scripts-ref: ${{ github.event.pull_request.head.sha || github.sha }} | ||
# machine: raspberrypi3 | ||
# sign-image: false | ||
# os-dev: false | ||
# deploy-s3: true | ||
# deploy-hostapp: true | ||
# deploy-ami: false | ||
# deploy-esr: false | ||
# finalize-hostapp: "no" | ||
# run-tests: true | ||
# test-suites: os | ||
# test-environment: balenaos-balenamachine | ||
# test-workers: testbot | ||
# meta-balena-ref: f2a99b11212c2e3eed74dbc26abc5cf96d3b2726 |
Oops, something went wrong.