* ci: add coverage workflows (per-module + global gcovr)
Adds two GitHub Actions workflows under .github/workflows/ that call
the shared nasa/fprime-actions/coverage-common composite action:
coverage-check.yml - PR job. Triggers on pull_request to devel.
Computes per-module + global coverage on the
PR head, then writes a sticky comment to the
PR with the delta vs. the baseline stored at
nasa/fprime-coverage's coverage/<base_ref>
branch.
coverage-update.yml - Push job. Triggers on push to devel. Computes
coverage on the new tip and mirrors it into
nasa/fprime-coverage at coverage/devel for
future PR-jobs to baseline against.
Both workflows pin runs-on: ubuntu-24.04 because gcov-11 (the default
on ubuntu-22.04) has counter-overflow bugs (gcc#68080) and pathological
slowness on heavily-templated test code; gcov-13 (the default on
ubuntu-24.04) fixes both regressions. See the runner-version section
in nasa/fprime-actions/coverage-common/README.md for details.
For v1 the workflows are comment-only -- no merge gating, no required
status check. The sticky PR comment surfaces global headline coverage
+ per-module table + Largest Changes table so reviewers and the PR
author can see the impact of their changes without leaving the PR.
The PR comment renders module rows for every register_fprime_module(...)
directory that also declares register_fprime_ut(...). Modules whose
UT build fails (or whose gcovr run fails) surface as 'no coverage' rows
rather than killing the job (lenient by default; the action exposes a
'strict: true' input for callers that want hard gating).
Touches only the .github/ tree and the spell-check expect list. No
runtime code or tests are modified.
* ci(coverage): split into pull_request + workflow_run stages
Cross-fork PRs (e.g. JPL-Devin/fprime -> nasa/fprime) cannot post a
sticky coverage comment from the pull_request workflow: GitHub strips
write permissions from GITHUB_TOKEN on fork-triggered pull_request
events, so the POST returns 403 'Resource not accessible by
integration' regardless of what permissions: block requests.
Adopt the GitHub-recommended two-stage pattern matching the upstream
nasa/fprime-actions split (coverage-check + coverage-comment):
coverage-check.yml (event: pull_request)
Runs on fork content with permissions: contents: read only.
coverage-check@devel now generates the comment + regressions data
and uploads them as a workflow artifact (also writes the body to
GITHUB_STEP_SUMMARY so reviewers see the data on the Actions run
page). Drop pull-requests: write from the permissions block since
it is no longer needed and is silently ignored on fork PRs anyway.
coverage-comment.yml (event: workflow_run) [new file]
Triggered when Coverage Check completes successfully on a
pull_request event. Runs under the base repo's elevated token
with permissions: actions: read + pull-requests: write. Calls
coverage-comment@devel, which downloads the artifact from the
triggering run and upserts the sticky comment. Safe to grant
write because no fork code executes here.
The two-stage pattern means coverage-comment.yml must itself be on
nasa/fprime's default branch before workflow_run can fire it. For
this PR that means: the artifact-upload + step-summary path will run
on every push, but the actual PR comment will start posting only on
PRs landing AFTER this change merges to devel. This is an unavoidable
consequence of workflow_run requiring the listener workflow file to
exist on the default branch.
---------
Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
A Flight-Proven, Multi-Platform, Open-Source Flight Software Framework
F´ (F Prime) is a component-driven framework that enables rapid development and deployment of spaceflight and other embedded software applications. Originally developed at the Jet Propulsion Laboratory, F´ has been successfully deployed on several space applications. It is tailored but not limited to small-scale spaceflight systems such as CubeSats, SmallSats, and instruments.
Please Visit the F´ Website: https://fprime.jpl.nasa.gov for more information.
What does F´ provide
- An architecture that decomposes flight software into discrete components with well-defined interfaces
- A C++ framework that provides core capabilities such as message queues and threads
- Modeling tools for specifying components and connections and automatically generating code
- A growing collection of ready-to-use components
- Testing tools for testing flight software at the unit and integration levels.
Learn more about F´ key features.
System Requirements
The following system requirements apply to your workstation for developing F´ applications. To see the list of supported platforms on which F´ applications can run on, see Supported Platforms.
-
Linux, Windows with WSL, or macOS operating system
-
Clang or GNU C and C++ compilers (e.g. gcc and g++)
Click to Expand: How to Verify System Requirements
-
git --version -
python --versionandpython -m venv -h. Your system might use an alternate likepython3orpython3.13. For pip:pip --version. On your system it might bepip3orpipx. -
g++ --versionand then create, build, and run a test program. For example, create a file namedhello.cppwith contents:#include <iostream> int main(void){ std::cout << "Hello, World!" << std::endl; }then build and run it, for example like:
% g++ -o hi hello.cpp % ./hi Hello, World!
Getting Started
To get started with F´, install the F´ bootstrapping tool with:
pip install fprime-bootstrap
Then, create a new project with:
fprime-bootstrap project
See the HelloWorld Tutorial to guide you through all the steps of developing an F´ project.
New users are encouraged to read through the User Manual and explore the other tutorials.
Getting Help
Discussions
To ask questions, discuss improvements, and ask for help please use the project's GitHub Discussions.
Bug reports
To report bugs and issues, open an issue here.
Community
The F´ Community GitHub Organization contains third party contributions, more documentation of flight software development, and additional resources.
Resources
Meet the Team
The following roles are members of the CCB and per our governance document have decision making power within the framework.
| Role | Team Member |
|---|---|
| Community Manager | @LeStarch |
| Community Manager | @thomas-bc |
| Community Manager | @kevin-f-ortega |
| Security Overseer | @bitWarrior |
| CCB Member | @bocchino |
| CCB Member | @kevin-f-ortega |
| CCB Member | @SterlingPeet |
| CCB Member | @timcanham |
| CCB Member | @zimri-leisher |
Each product has a set of Maintainers who are charged with the day-to-day implementation of the CCB's direction as realized in a by product.
| Product | Core Maintainer(s) |
|---|---|
| F Prime | @LeStarch, @thomas-bc |
| F Prime (v3.6.x Maintenance) | @SterlingPeet |
| fprime-tools | @thomas-bc, @LeStarch |
| fprime-gds | @thomas-bc, @LeStarch |
| fpp | @bocchino, @Kronos3 |
| F Prime Platforms | @kevin-f-ortega, @LeStarch |
| Security | @bitWarrior |
Release Notes
The version history and artifacts associated with the project can be found at Releases.