lestarch-autobot 37931e8ea1 ci: add coverage workflows (per-module + global gcovr, two-stage) (#5167)
* 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>
2026-05-28 14:54:19 -07:00

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.

  1. Linux, Windows with WSL, or macOS operating system

  2. git

  3. Python 3.10+, virtual environments, and PIP

  4. Clang or GNU C and C++ compilers (e.g. gcc and g++)

Click to Expand: How to Verify System Requirements
  1. git --version

  2. python --version and python -m venv -h. Your system might use an alternate like python3 or python3.13. For pip: pip --version. On your system it might be pip3 or pipx.

  3. g++ --version and then create, build, and run a test program. For example, create a file named hello.cpp with 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.

Description
v4.0.0 Latest
2025-08-06 19:42:06 -05:00
Languages
C++ 86.4%
CMake 6%
Fortran 5.1%
Python 1.5%
C 1%