id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
3653	Use newer coveralls version in GitHub Actions	sajith	sajith	"This is related to [https://github.com/tahoe-lafs/tahoe-lafs/pull/986 the discussion] about #3616.

While working on #3616, it turned out that coveralls-python (henceforth ""coveralls"") maintains two separate, slightly incompatible, versions for Python 2 and Python 3.  At this time of writing,  coveralls 1.11.1 will be installed for Python 2.7, and coveralls 3.0.1 will be installed for Python 3.x.  

The newer version of coveralls has a `--finish` option, which is useful to indicate to coveralls.io that a number of parallel builds have finished.  Without this option, we will have to manually construct some parameters and use `curl` to do the same, as done here:

https://github.com/LeastAuthority/tahoe-lafs/blob/786433056231320ef994b63ff7b61bc3ff9e940c/.github/workflows/ci.yml#L107-L185

That should be fine, except when CI needs to run Python 2.7 tests and Python 3.x tests in parallel.  In the same CI run, IDs generated by the two versions of coveralls will be of different types: older coveralls gets something like `cc6f006336de603b95c183e4e80e059b88f20b8d-PR-986.2`, and newer one gets `630187837.1`. If we mix coveralls 1.x and 3.x in the same CI run, coveralls.io will have trouble matching up the jobs, and will never send coverage status back to !GitHub.

We could invoke the newer version of coveralls uniformly, relying on the fact that !GitHub Actions tool cache already has Python3 and pip3, even when a CI job is set up to run Python 2.7 tests."	defect	closed	normal	undecided	dev-infrastructure	n/a	fixed