Branches not correctly fetched from github - badge not showing

[jhannes]

In one of my repositories, the builds in Coveralls are linked to commit hashes instead of the main branch. The repository in question is https://coveralls.io/github/jhannes/logevents?branch=main

I suspected that the reason for this was that I renamed the default branch from master to main and Coveralls was unable to sync the branch names, so I tried to delete the repository in coveralls and recreate it but the problem persists.

When I try to sync branches, the progress spinner never stops. This is due to a 500 while performing the request https://coveralls.io/repos/351454/sync_branches.json

[afinetooth]

@jhannes will look into this asap as the site is currently in emergency maintenance:
https://status.coveralls.io/

I suspect the 500 error you received on Friday related to the root cause for the original maintenance window, which started then.

[afinetooth]

Hi @jhannes I checked this morning and your latest build appears normal and your default branch shows as main with no new info detected upon a repo sync. This indicates things should be back to normal. Let me know if not.

[andyholmes]

I had the same problem after changing my branch from master to main, which happened to occur during the maintenance period. I had tried refreshing the repository info without success so I deleted and re-added the repo.

After some time (over an hour at least) I finally got results on coveralls.io. It's possible there's just a backlog after coveralls came back online, so maybe if I had waited if it would have succeeded updating by itself.

[jhannes]

@afinetooth I still have a commit hash showing instead of the main branch, the "sync branches" button spinning forever and a failed request to https://coveralls.io/repos/351454/sync_branches.json with 500.

[afinetooth]

Hi @jhannes. Thanks for you patience.

So that 500 you're receiving is because we can't find the branch to sync and (probably obvious) that's because we're not receiving branch names, but rather the hashes you mention.

The Coveralls API will accept whatever you pass it for branch in the git hash for your job's POST, so I have every reason to believe the branch value is coming across from your CI as one of those hashes (likely from being in detached HEAD state). which means the tuning needs to be done on the CI side.

We can verify that by running a new build, or re-running an old build in verbose mode, which adds debug output to your CI build log and shows the exact JSON you're POSTing to the Coveralls API.

I can't tell what CI you're using from your build pages, for example:
https://coveralls.io/builds/42996638

But I can see you're building a Java project.

The way to enable verbose mode will depend on the integration you're using, so if you are using the community-created Java integration listed here (coveralls-maven-plugin), this is the closest thing to a debug flag I can find.

If you are using coveralls-maven-plugin, you may want to search the project's issues to see if other users mention it, or ask there how to enable debug mode.

Likewise, if you're using a different Java integration, you can consult that project's README or issues.

Let me know what Java integration you're using and I'll try to help with that.

Another way to enable verbose mode is available through a couple of CI-specific coveralls tools, like the Coveralls Orb for CircleCI and the Coveralls Github Action. Those come with their own debug flag, which we can employ if you're using one of those (let me know).

Once we can examine the git hash param in the JSON you're sending to the Coveralls API, we can verify your CI is sending a hash (likely from building in detached HEAD state) instead of the current branch, and proceed on fixing that.

Otherwise, if you take my suspicion as a viable assumption and you know how to get your CI to pass the branch name, such as by reverting from detached HEAD state or pulling the branch in a step before running coveralls, the issue might fix itself.

Let me know how I can help from here.

[afinetooth]

@andyholmes if you'd like some help with your project, I'll need to know the Coveralls URL for your repo and/or a specific build URL. Thanks.

[andyholmes]

@afinetooth All good :) I thought I had the same problem, but it resolved itself. Thanks!

[afinetooth]

@andyholmes great.

[jhannes]

@afinetooth Thank you for following up. It took me a while to make the necessary investigations.
When I run it on Github Actions the value of branch is null. However, when I run it locally, it correctly lists branch: "main".

I am stumped why this may be as I have several other projects with Coveralls that seem run correctly in Github Actions, for example https://github.com/jhannes/action-controller

[afinetooth]

Hi @jhannes, unless I'm wrong, it looks like you're getting hashes for branch names in this project too:

https://coveralls.io/github/jhannes/action-controller

This issue crops up from time-to-time and I haven't been able to identify a single cause, only case-by-case solutions. Usually, the issue is related to default CI configuration, using a self-hosted runner, doing a squash merge or rebase right before your build, etc.

Without figuring out why CI is passing a hash instead of a branch name, the solution is usually something as simple as adding a step to your CI config file that does a git checkout on the branch, which seems to add the branch name to the appropriate CI env vars.

Unfortunately, since you're not using the Coveralls Github Action, I can't offer a verbose flag to add debug output to your build log. It could be useful to see what CI is providing in the git hash. However, it's just as likely all we'll do is confirm that it's populating git["branch"] with the hash we're seeing in your build history (like the above screenshot).

Can you try adding a git checkout (on the current branch) to your GHA config YAML somewhere before this line?

You're basically trying to get CI / git out of "detached HEAD" state, which CI may be building in for various reasons (squash merge, rebase, etc.). This explanation from Bitrise CI docs is as good as any I've seen on what that state is and how to "recover" from it. This blog post is good too.

[jhannes]

I made a quick effort to do a git checkout, but it didn't seem to change things. It sounds like using the Coveralls Github Action would be a good way forward, but I can't find a Maven plugin that generates lcov-files. Is there are tutorial anywhere?

[afinetooth]

Hi @jhannes, yes, that is a limitation users of some languages run into (Java, Python). On the python side, there's a separate community-created Github Action used by many python devs here.

From this issue, I found this resource:
https://github.com/danielpalme/ReportGenerator

ReportGenerator converts coverage reports generated by coverlet, OpenCover, dotCover, Visual Studio, NCover, Cobertura, JaCoCo, Clover, gcov or lcov into human readable reports in various formats.

Doesn't exactly match your need from that description, but this list of its Output Formats indicates LCOV might be an export format:
https://github.com/danielpalme/ReportGenerator/wiki/Output-formats

This online configuration tool also indicates you can pick LCOV as the output format for any input format, like XML:
https://danielpalme.github.io/ReportGenerator/usage.html

Another thing: The tool appears to be for use with .NET, but it looks like they have a package for Github Actions here:
https://github.com/marketplace/actions/reportgenerator

Support for Github Actions is something users of the coveralls-maven-plugin have been asking for as well, apparently. You might find something helpful in that regard, in the body of this issue:
trautonen/coveralls-maven-plugin#136

Hope that helps!

[stale]

This issue has been automatically marked for closure because it has not had recent activity. It will be closed if no further activity occurs. If your issue is still active please add a comment and we’ll review as soon as we can. Thank you for your contributions.