Code Coverage Report

A GitHub Action to generate a comment within Pull Requests with the latest code coverage metrics for that branch.

How to use

This action may be called from within any workflow that produces a lcov.info file. Generally, this would be created by the test engine of whatever programming language is being used. The code coverage action exposes the following inputs for customizing the report.

• github_token

  This is the permissions token passed from the calling workflow. It is used to call the GitHub API and add the coverage report to the Pull Request.

  Default: The github.token inherited from the calling workflow. Ensure the permissions for the job are set so that this action can leave comments in the pull request.

• coverage_file

  This is the path to the lcov.info (or whatever name you give it - it must be in the format of a lcov.info file) from the project's root directory.

  Default: coverage/lcov.info

• coverage_threshold

  This is the targeted percentage of code coverage. Any coverage percentage less than this (in a single file, across a directory, or across the entire project) will be marked with a ' ⛔ '. Any coverage within 10% of the threshold will be marked with a ' ⚠️ '. Finally, any percentage greater than that will be marked with a ' ✅ '.

  Example: coverage_threshold: 80

  • 0% - 79% is marked with ⛔
  • 80% - 88% is marked with ⚠️
  • 89% - 100% is marked with ✅

  Default: 80

• include_pattern

  This is a regex pattern to denote the sorts of files that require test coverage. For example, in a Dart project, this would be all the files that have the .dart suffix.

  This value is required.

• exclude_pattern

  This is a regex pattern to denote any files that should be ignored by the coverage calculation.

  Again, taking Dart as an example, all the test files end with .dart, but we don't want those files crushing the test coverage metrics (why would we write tests to cover our tests? Then we'd need tests for those tests, and now we're creating an infinity of tests...). Because all the Dart tests live in the test/ directory, we can add a pattern here that excludes any filepath with test/ in it.

  Default: none — when omitted, no files matching include_pattern are excluded.

Example workflow

name: Some workflow

on:
  [your workflow triggers]

jobs:
  a-job:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    steps:
      ...
      - name: Run tests with coverage
        run: <some command that generates the lcov.info file>
      - name: Generate coverage report
        uses: fermi-ad/code-coverage-reporter@<release tag or commit hash>
        with:
          include_pattern: <some regex matching files to report coverage for>
          exclude_pattern: <some regex matching files that would be included, but are not intended for code coverage reporting>
      ...

How it works

The action parses the LCOV report in a multi-step pipeline:

1. parse() — reads each SF: record from the LCOV file and builds an in-memory tree of FileCoverage and DirectoryCoverage nodes.
2. findRoot — descends single-child directory chains to strip container-path prefixes that CI environments (e.g. /workspace/my-project/) prepend to every source path.
3. resolveRootFsPath — locates the matching directory on the local filesystem by name, validating the match against known cache children.
4. applyRecursiveMatchRules — walks the filesystem and reconciles it against the parsed cache: files present on disk but absent from the LCOV report are added with 0% coverage, entries matching exclude_pattern are replaced with ExcludedCoverage records, and empty directories are pruned.

Build

This is a JavaScript GitHub action, with index.js as its entry point. To ensure dependencies are correctly aligned for use within CI/CD pipelines, the "development" code must be packaged into a "production" index.js.

All source code is within the src/ directory, and the executed code is compiled to dist/index.js. If any changes are made in src/, a new dist/index.js must be built.

Note: As of April 2026, GitHub Actions will stop supporting Node.js 20 by default. The latest long-term-support version is Node.js 24. Make sure this is the version of Node you have installed before modifying this repository.

Packaging

This repository comes with a build script for automatically packaging the "production executable" as needed. To generate a version that includes changes to the source files, do the following:

1. Install the project dependencies

The package-lock.json will have the current dependency versions specified. Make sure you have them loaded by running

npm ci

2. Run the tests to ensure accuracy

Testing has been configured within the package.json file. Simply run

npm run test

3. Build the distributable

Generate the executable JS file with

npm run build

Example output

---

Code Coverage Report - 416 of 495 lines covered ( ⚠️ 84.04%)

src - 416 of 495 lines covered ( ⚠️ 84.04%)

 ### db - 90 of 123 lines covered ( ⛔ 73.17%)

  ### mod.rs - 90 of 90 lines covered ( ✅ 100.00%)

   

Etc...

---

---