Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Branch not reported correctly on coveralls.io #1697

Open
bitfl0wer opened this issue Feb 23, 2025 · 2 comments
Open

Branch not reported correctly on coveralls.io #1697

bitfl0wer opened this issue Feb 23, 2025 · 2 comments
Assignees

Comments

@bitfl0wer
Copy link

I am using tarpaulin with coveralls.io. coveralls supports viewing coverage on branches. However, coverage data generated from runs on branches does not get recognized correctly:

Screenshot of a CI (Continuous Integration) dashboard titled “RECENT BUILDS.” The table displays eight rows, labeled #8 through #1, with column headers for “BUILDS,” “BRANCH,” “COMMIT MESSAGE,” “TYPE,” “RAN,” “COMMITTER,” “VIA,” and “COVERAGE.” Each row shows a build number, the corresponding Git branch (e.g., “main”), a short commit message (including one reading “use LLM and no-dead-code as recommended by tarpaulin for linux” and another reading “[no commit message]”), the build trigger type (“push”), the date and time the build ran, the committer (displayed as “bottower”), how it was triggered (“via bottower”), and a coverage percentage in the last column (ranging around the 66–76% range in red and orange bars). Notably, the coverage values appear inconsistent for branch builds, suggesting that coverage runs on non-main branches are not being recognized correctly (some entries are missing or remain at an unexpected value), whereas main branch builds do show an updated coverage percentage.

GitHub actions workflow

runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: Swatinem/rust-cache@v2
        with:
          cache-all-crates: "true"
          prefix-key: "coverage"
      - name: Build, Publish Coverage
        run: |
          if [ -n "${{ secrets.COVERALLS_REPO_TOKEN }}" ]; then
              curl -L --proto '=https' --tlsv1.3 -sSf https://raw.githubusercontent.com/cargo-bins/cargo-binstall/main/install-from-binstall-release.sh | bash
              cargo binstall --no-confirm cargo-tarpaulin --force
              cargo tarpaulin --no-dead-code --engine llvm --all-features --tests --verbose --skip-clean --coveralls ${{ secrets.COVERALLS_REPO_TOKEN }} --timeout 120
          else
              echo "Code Coverage step is skipped on PRs from forks."
          fi

Expected outcome

In this scenario, I'd expect the branch name and commit message data to be submitted to coveralls correctly. Am I doing something wrong with my command invocation?

@xd009642
Copy link
Owner

It looks fine on your end so it's probably me. I'll check the coveralls API tomorrow and make sure I'm not missing out on any of the optional fields I can set in the request!

@bitfl0wer
Copy link
Author

Interestingly, I just created a new branch and committed it. That seems to have been picked up as intended.

Screenshot of a CI pipeline dashboard titled “RECENT BUILDS,” now displaying nine rows labeled #10 through #2 (with each row showing build number, branch name, commit message, build trigger type, timestamp, committer, and coverage). The top row, build #10 on the “coverage” branch, has a commit message “try excluding trace/ calls to increase coverage,” run via push on 23 Feb 2025 at 02:49 PM CEST by user “bottower,” and shows a coverage percentage of 72.00%. Below it, builds #9 through #2 list either “[no commit message]” or specific messages (like “use LLM and no-dead-code as recommended by tarpaulin for linux”), all with coverage values in the 66–72% range. Unlike the previous screenshot, the coverage data now appears consistently recognized across all branches, suggesting that the earlier coverage-detection issue has been resolved.

Making a second commit on this new branch also works. Perhaps, it is important to point out, that the "troubled" branch is called "dev/v0.10". Maybe that's part of the issue. Hope this helps somewhat :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants