Issue with COVERALLS_FLAG_NAME statement in "Github Actions Gotcha" doc section

[andy-maier]

The documentation states in section Github Actions Gotcha:

For parallel builds, you have to add a final step to let coveralls know the parallel build is finished. You also have
to set COVERALLS_FLAG_NAME to something unique to the specific step, so re-runs of the same job don’t keep
piling up builds:

I think that COVERALLS_FLAG_NAME is not required (maybe it was in the past?), and that if provided it does not need to be unique. I have successfully used version 2.1.2 of coveralls in parallel mode on GitHub Actions without specifying COVERALLS_FLAG_NAME. The resulting jobs combine successfully on coveralls.io. The identification string contains GITHUB_RUN_ID and a sequence number in any case, and COVERALLS_FLAG_NAME only adds to it:

• Example without specifying it: https://coveralls.io/builds/35000108
• Example with specifying it with unique values: https://coveralls.io/builds/34998052 (has more entries than expected probably due to several experiments, but that's beyond the point I am making)
• Example with specifying it with the same value: https://coveralls.io/builds/35001351

I suggest to clarify that in the docs.

[andy-maier]

Addressed by PR #244.

[andy-maier]

Update: I played around with re-running jobs (via GitHub Actions re-run) and the effect is that coveralls.io still combines the jobs properly into a consolidated result for the same build, but in its list of it jobs within the build it shows e.g. 13 instead of the expected 10 jobs. I assume that is what the original text described in its statement about "piling up builds". However, it turns out that ths "piling up" happens in all of the three cases described above. You can see that in the linked examples, each of them should show 10 jobs in the build, but they show more. So while there is a "piling up bug" somewhere, it is not circumvented by specifying a unique value for COVERALLS_FLAG_NAME, as the original text had suggested. Also, very strange: The number of jobs shown for a build varies within certain limits when refreshing the browser window. That happens for all three cases.

Bottom line: When reviewing the PR, one consideration might be to describe the "piling up" effect, but at this point I'm not sure we have a way to avoid it, so the question is, is it worth while to say something about it. After all, the combined coverage result seems to be ok in all three cases, as far as I can tell.

[TheKevJames]

Thanks again for the PR!