Skip to content

Commit

Permalink
Create workflow to build and deploy balenaOS
Browse files Browse the repository at this point in the history
Change-type: minor
Signed-off-by: Kyle Harding <[email protected]>
  • Loading branch information
klutchell authored and rcooke-warwick committed Jun 6, 2024
1 parent 466d6ec commit ab8da33
Show file tree
Hide file tree
Showing 3 changed files with 1,350 additions and 0 deletions.
36 changes: 36 additions & 0 deletions .github/workflows/README.md
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 | |
120 changes: 120 additions & 0 deletions .github/workflows/generic-amd64.yml
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
Loading

0 comments on commit ab8da33

Please sign in to comment.