Builds aren't aggregated when used with circle ci parallel builds

[ianwremmel]

I can't tell if this is a bug with node-coveralls or with the coveralls service itself but it seems like the circle ci build number doesn't get pushed to coveralls.

Builds 9 through 12 at https://coveralls.io/github/ciscospark/spark-js-sdk all refer to the same circle build, but seem to replace the total coverage instead of aggregating.

[CoreyCole]

I'm looking into how to do parallel build aggregation on codeship. At the end of all the builds running, I'm running a custom bash script to run curl

COVERALLS_ENDPOINT=https://coveralls.io
curl -k $COVERALLS_ENDPOINT/webhook?repo_token=$COVERALLS_REPO_TOKEN -d "payload[build_num]=$BUILD_NUMBER&payload[status]=done"

Following documentation here

I think on circle CI it seems more working right out of the box. But, it looks like you might need to provide a $BUILD_NUMBER somewhere.

I'm wondering how I might get the most recent build number, increment it, and then set it in my environment variables for all my parallel builds?

[CoreyCole]

Looks like this might not be currently possible with node-coveralls #107

Not sure if it is still the case

[gynnantonix]

According to this discussion, node-coveralls needs to include the service_number parameter in the object it sends to Coveralls. It's used as the grouping criteria for identifying jobs that are part of the same build. It should be set to whatever ID is used as build_num when hitting the parallel builds webhook.

For example, in Circle, this could be the Workflow UUID.

[nickmerwin]

Hi all, we've released a new version that uses Circle's Workflow ID for parallel job merging.

Our Orb is also updated: https://circleci.com/orbs/registry/orb/coveralls/coveralls