- GHA release workflow is updated to use an action for uploading all assets. The action docs say it updates a release if one already exists, and since this triggers on release and we pass a release tag we know the release already exists. - GHA release candidate workflow is updated to auto-publish a pre-release release on push to a `release/**` branch. A script is added and used to generate a release message made up of the commits since the last release of any kind. - ACT profiles are added to allow locally testing these workflows without needing to push and wait for GHA to run. - Docs are updated to note how to test the workflows locally.
3.7 KiB
Testing and Debugging
CrossPoint runs on real hardware, so debugging usually combines local build checks and on-device logs.
Local checks
Make sure clang-format 21+ is installed and available in PATH before running the formatting step.
If needed, see Getting Started.
./bin/clang-format-fix
pio check --fail-on-defect low --fail-on-defect medium --fail-on-defect high
pio run
Flash and monitor
Flash firmware:
pio run --target upload
Open serial monitor:
pio device monitor
Optional enhanced monitor:
python3 -m pip install pyserial colorama matplotlib
python3 scripts/debugging_monitor.py
Test release workflows locally with act
Use act to dry-run the release workflows
after modifying them. Running locally with act is faster and more iterative
than pushing commits to GitHub and waiting for Actions to run. It will test the
entire workflow, including job conditions and release-notes generation, without
actually publishing releases or uploading assets.
For this repository, local act runs simulate different GitHub event types for
the two release workflows:
release.ymlis exercised with a simulatedreleaseevent whose action ispublishedrelease_candidate.ymlis exercised with a simulatedpushevent on arelease/**branch
What local act runs validate
Local runs are useful for validating:
- workflow wiring and job conditions
- PlatformIO release builds
- release-notes generation via
scripts/generate_release_notes.py
Local act runs do not publish GitHub releases or upload release assets.
Those steps are skipped when ACT=true, so final release publication still
requires a real GitHub Actions run.
Prerequisites
actinstalled locally- Docker available and running
- Podman will most likely also work. Ensure the rootless user socket is
configured and set
DOCKER_HOSTto its path (e.g.export DOCKER_HOST=unix:///run/user/1000/podman/podman.sock).
- Podman will most likely also work. Ensure the rootless user socket is
configured and set
ghCLI authenticated (gh auth status)- event payload files in
.github/act/
Included payload files:
.github/act/release-published.jsonto simulate therelease.publishedevent used byrelease.yml.github/act/release-candidate-push.jsonto simulate the branch-push event used byrelease_candidate.yml
Provide GITHUB_TOKEN safely
Release-notes generation expects GITHUB_TOKEN. Prefer exporting it from gh
instead of pasting a token directly into shell history:
export GITHUB_TOKEN="$(gh auth token)"
Then pass it to act by name:
act ... -s GITHUB_TOKEN
Unset it when finished:
unset GITHUB_TOKEN
Run the stable release workflow locally
act release \
-W .github/workflows/release.yml \
-e .github/act/release-published.json \
-s GITHUB_TOKEN
Run the release-candidate workflow locally
act push \
-W .github/workflows/release_candidate.yml \
-e .github/act/release-candidate-push.json \
-s GITHUB_TOKEN
What still needs a real GitHub run
After a local act pass, a real GitHub Actions run is still required to verify:
- GitHub release creation
- asset upload
- workflow permissions and repository-token behavior
- the exact GitHub-hosted runner environment
Useful bug report contents
- Firmware version and build environment
- Exact steps to reproduce
- Expected vs actual behavior
- Serial logs from boot through failure
- Whether issue reproduces after clearing
.crosspoint/cache on SD card