Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create workflow to build and deploy balenaOS #329

Merged
merged 1 commit into from
Jun 6, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
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
Loading