Include Bazel external coverage HTML in uploaded artifact

[Copilot]

The coverage workflow generates links to Bazel external-source pages (for example .../.bazel/execroot/_main/external/flatbuffers+/...), but those pages were missing from the uploaded artifact. As a result, external coverage links in the HTML report were broken even though external files were present in the tracefile.

• Root cause

  • actions/upload-artifact@v6 defaulted to excluding hidden paths, which dropped .bazel/... content from cpp_coverage/.
  • genhtml produced external links/pages under execroot-shaped paths, but upload omitted that hidden subtree.

• Workflow changes

  • Preserve hidden coverage output in artifact upload:
    • set include-hidden-files: true on the coverage artifact step.
  • Add a guardrail step after genhtml:
    • if the tracefile contains /external/ sources, require generated external HTML to exist under cpp_coverage/<execroot>/external.
    • fail early when external pages are expected but not present.

• Why this resolves the issue

  • External coverage is still included (not filtered out), and the artifact now retains the .bazel path hierarchy that report links target.

- name: Upload Coverage Artifacts
  uses: actions/upload-artifact@v6
  with:
    name: ${{ github.event.repository.name }}_cpp_coverage_report
    path: cpp_coverage/
    include-hidden-files: true
    retention-days: 10

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• releases.bazel.build
  • Triggering command: /usr/local/lib/node_modules/@bazel/bazelisk/bazelisk-linux_amd64 /usr/local/lib/node_modules/@bazel/bazelisk/bazelisk-linux_amd64 --version (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

The GitHub Actions coverage workflow in repository paulquiring/baselibs generates an HTML coverage artifact with links that reference Bazel external dependency coverage pages such as baselibs_cpp_coverage_report/home/runner/.bazel/execroot/_main/external/flatbuffers+/include/flatbuffers/index.html, but those expected pages are missing from the uploaded artifact.

Relevant workflow file:

• .github/workflows/coverage_report.yml

Relevant failing run/job reference provided by the user:

• Run: 26232556691
• Job: 77196693828
• Workflow: Code Coverage
• Job URL: https://github.com/paulquiring/baselibs/actions/runs/26232556691/job/77196693828

Current workflow behavior:

• Runs bazel coverage --config=bl-x86_64-linux -- //score/... -//score/language/safecpp/aborts_upon_exception:abortsuponexception_toolchain_test
• Generates HTML coverage using genhtml "$(bazel info output_path)/_coverage/_coverage_report.dat" -o=cpp_coverage --show-details --source-directory="$(bazel info execution_root)" --legend --function-coverage --branch-coverage --ignore-errors negative
• Uploads cpp_coverage/ as the artifact

The user explicitly requires coverage for external files to be uploaded, not filtered out.

Please create a pull request that updates the coverage workflow so that the generated HTML artifact correctly includes and/or preserves coverage pages for Bazel external files (for example under external/flatbuffers+). Investigate and implement a robust fix. This may involve adjusting how genhtml is invoked, validating or normalizing Bazel execroot/external path handling, generating missing directory pages, copying or restructuring generated output so links resolve correctly in the uploaded artifact, and/or adding verification steps so the artifact contains the expected external coverage HTML pages.

Requirements:

• Do not exclude external dependency coverage from the report.
• Ensure the uploaded artifact contains working HTML pages for external sources referenced by the report.
• Keep the workflow concise and maintainable.
• Update only what is necessary for this fix.
• The PR description should explain the root cause and how the workflow change fixes it.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: The generated html coverage report states

baselibs_cpp_coverage_report/home/runner/.bazel/execroot/_main/external/flatbuffers+/include/flatbuffers/index.html

should exist but it does not.

Assistant: The problem is most likely genhtml is generating links for files under Bazel’s external workspace tree, but those source files are not actually present under the uploaded report output, so the HTML points at a path that cannot be resolved.

The key evidence is in the workflow:

- name: Generate HTML Coverage Report
  run: |
    genhtml "$(bazel info output_path)/_coverage/_coverage_report.dat" \
      -o=cpp_coverage \
      --show-details \
      --source-directory="$(bazel info execution_root)" \
      --legend \
      --function-coverage \
      --branch-coverage \
      --ignore-errors negative

--source-directory="$(bazel info execution_root)" tells genhtml to resolve source paths relative to the Bazel execution root, which includes paths like:

• /home/runner/.bazel/execroot/_main/...
• /home/runner/.bazel/execroot/_main/external/flatbuffers+/include/...

So when coverage data includes headers from FlatBuffers, genhtml emits links for them. But in the artifact you upload, only cpp_coverage/ is archived, not the Bazel execution root or external repos. That means links such as:

• baselibs_cpp_coverage_report/home/runner/.bazel/execroot/_main/external/flatbuffers+/include/flatbuffers/index.html

can be referenced by the report but the corresponding generated pages may never exist if:

1. genhtml skipped those files,
2. path rewriting for external sources was inconsistent,
3. or the artifact browser is trying to interpret absolute-source-based links that don't map cleanly inside the uploaded artifact.

From the logs, coverage processing is continuing across many files and only shows generic --- ERROR --- separators, not a hard failure specifically on FlatBuffers. That suggests the report generation itself mostly completed, but some per-file pages were omitted or linked incorrectly.

Most likely root cause:

• external dependency headers from Bazel (external/flatbuffers+) are present in the coverage data,
• but genhtml output does not contain a matching page tree for every referenced external file,
• so the top-level HTML references nonexistent pages.

Best fixes, in order:

1. Exclude external dependencies from coverage input before running genhtml.
   • This is usually the cleanest fix because vendored/external headers should n...

This pull request was created from Copilot chat.