This document provides a comprehensive overview of all GitHub workflows and bash scripts in the EmotiBit FeatherWing repository.
- GitHub Workflows
- Bash Scripts
- Development Process
- Dependency Management Approaches
- Configuration Files
- Requirements Summary
- Maintenance Notes
The repository uses two GitHub Actions workflows to automate the build and release process. These workflows are defined in .github/workflows/.
File: .github/workflows/build-and-upload-binaries.yml
When it runs: Automatically on every push to any branch
What it does: Provides continuous integration by building firmware binaries for every commit, ensuring code changes compile successfully.
For developers:
- Push to any branch triggers an automatic build
- Check the Actions tab to see build status
- Build artifacts (
.binand.hexfiles) are available for download for 30 days - Artifacts include both firmware variants plus a dependency report
- Artifact naming:
emotibit-firmware-{version}(version fromlibrary.properties)
Why it's useful:
- Validates that changes compile before merging
- Provides downloadable binaries for testing without local builds
- Generates a dependency snapshot for each build
- Ensures all branches maintain buildable state
Technical notes:
- Uses
download_dependencies.sh,generate_dependency_report.sh, andbuild.sh - Automatically cleans up build environment after completion
File: .github/workflows/create-release.yml
When it runs: Manually triggered via GitHub Actions UI
What it does: Creates a GitHub release using binaries from the latest successful dev branch build.
For developers - How to create a release:
- Ensure the
devbranch has a successful build - Go to Actions → "Create Release from Latest CI Build" → "Run workflow"
- Optionally provide:
- Custom release name (defaults to
v{version}from library.properties) - Pre-release flag (for beta/RC releases)
- Custom release name (defaults to
- Click "Run workflow"
- Workflow creates a draft release - review it before publishing
What gets included:
- Stock firmware binaries (
.binand.hexfiles) from both variants - Auto-generated release notes with:
- Link to the source build workflow run
- Library dependency versions and git commits
Important constraints:
- Only creates releases from the
devbranch - Requires at least one successful build on
dev - Releases are created as drafts for manual review
- Version tag format:
v{version}(e.g.,v1.14.3)
Best practices:
- Always verify the version number in
library.propertiesbefore creating a release - Review the draft release before publishing
- Use pre-release flag for beta/testing versions
- Ensure changelog/release notes are updated before publishing
These scripts are used by the GitHub workflows for automated builds and releases.
Location: ./download_dependencies.sh
Purpose: Downloads all project dependencies based on library.properties and depends_urls.json.
How it works:
- Reads dependency list from
library.properties - Gets GitHub repository URLs from
depends_urls.json - Parses dependency names and version specifications
- Clones each dependency repository at the specified version
- Downloads to the parent directory (same level as FeatherWing)
Features:
- Supports version pinning with format:
Name (=version) - Tries both
v{version}and{version}tag formats - Falls back to default branch if version tag not found
- Skips already downloaded repositories
- Shallow clone (--depth 1) for efficiency
Requirements:
jqcommand-line JSON processor- Git
Exit codes:
- 0: Success
- 1: Missing required files or tools
Location: ./generate_dependency_report.sh
Purpose: Generates a text report of all dependency versions and git commits.
Output: dependency_report.txt in the script directory
Report format:
EmotiBit FeatherWing Dependency Report
Generated: [timestamp]
LibraryName1: version (git_commit_hash)
LibraryName2: version (git_commit_hash)
...
How it works:
- Reads dependencies from
library.properties - Gets repository information from
depends_urls.json - For each dependency:
- Locates the downloaded repository
- Retrieves the current git commit hash
- Writes to report file
Requirements:
jqcommand-line JSON processor- Dependencies must be already downloaded
Location: ./build.sh
Purpose: Builds all EmotiBit FeatherWing firmware variants using PlatformIO.
Builds:
- EmotiBit stock firmware (
EmotiBit_stock_firmware/) - EmotiBit stock firmware PPG 100Hz (
EmotiBit_stock_firmware_PPG_100Hz/)
How it works:
- Checks if PlatformIO is installed
- Changes to each firmware directory
- Runs
pio runto build the firmware - Reports completion
Requirements:
- PlatformIO CLI (
piocommand) - All dependencies must be downloaded
Exit codes:
- 0: Success (all builds completed)
- 1: PlatformIO not installed or build failed
These scripts are for local development and manual dependency management.
Location: ./CloneEmotiBitFW.sh
Purpose: Clones all EmotiBit dependency repositories using SSH.
How it works:
- Calls
ExtractDepends.shto generate dependency list - Starts SSH agent and adds SSH key (
~/.ssh/id_ed25519) - Reads repository names from
EmotiBit_FeatherWing_depends.txt - Clones each repository from GitHub using SSH
- Clones to parent directory (one level up from current)
- Skips repositories that already exist
Requirements:
- SSH key configured for GitHub (
~/.ssh/id_ed25519) - SSH access to EmotiBit GitHub repositories
Note: This is a legacy script. The newer download_dependencies.sh is preferred for CI/CD as it uses HTTPS and supports version pinning.
Location: ./CheckoutMasterEmotiBitFW.sh
Purpose: Checks out the master branch for all dependency repositories.
How it works:
- Calls
ExtractDepends.shto generate dependency list - Starts SSH agent and adds SSH key
- Iterates through each repository
- Changes to repository directory and runs
git checkout master
Requirements:
- SSH key configured for GitHub
- Repositories must be already cloned
Use case: Useful for ensuring all dependencies are on the master branch for development or testing.
Location: ./ExtractDepends.sh
Purpose: Extracts dependency names from library.properties and writes them to a text file.
Output: EmotiBit_FeatherWing_depends.txt
How it works:
- Deletes existing
EmotiBit_FeatherWing_depends.txtif present - Reads
library.propertiesline by line - Finds the line starting with
depends= - Parses comma-separated dependency list
- Converts spaces to underscores in repository names
- Writes each repository name to the output file
Note: This script is called by other development scripts (CloneEmotiBitFW.sh, CheckoutMasterEmotiBitFW.sh, UpdateEmotiBitFW.sh) to generate the repository list.
Location: ./UpdateEmotiBitFW.sh
Purpose: Updates all dependency repositories by pulling latest changes.
How it works:
- Calls
ExtractDepends.shto generate dependency list - Starts SSH agent and adds SSH key
- Iterates through each repository
- Changes to repository directory and runs
git pull
Requirements:
- SSH key configured for GitHub
- Repositories must be already cloned
- No uncommitted changes in repositories (to avoid conflicts)
Use case: Quick way to update all dependencies to their latest versions.
The repository uses two different approaches for dependency management:
- Script:
download_dependencies.sh - Configuration:
library.properties+depends_urls.json - Method: HTTPS cloning with version pinning
- Advantages:
- No SSH key required
- Version control per dependency
- Works in CI/CD environments
- Follows Arduino library conventions
- Scripts:
CloneEmotiBitFW.sh,CheckoutMasterEmotiBitFW.sh,UpdateEmotiBitFW.sh - Configuration:
library.properties+ExtractDepends.sh - Method: SSH cloning without version pinning
- Advantages:
- Quick updates with git pull
- Works with existing SSH credentials
- Simple for local development
Recommendation: Use the modern approach (download_dependencies.sh) for reproducible builds and CI/CD. The legacy scripts remain useful for rapid local development iterations.
Feature Development:
1. Create feature branch from dev
2. Make code changes
3. Push to GitHub → automatic build runs
4. Download artifacts from Actions tab to test
5. Iterate on changes (each push triggers new build)
6. Create pull request to dev
7. Merge after review and successful build
Preparing a Release:
1. Update version in library.properties and merge featire branch to dev branch
2. Push changes → automatic build runs
3. Verify build succeeds on dev
4. Manually trigger "Create Release" workflow
5. Review draft release:
- Check binaries are correct
- Review auto-generated dependency information
- Add/edit release notes as needed
6. Publish release when ready