CI: De-flake coverage upload and stop fail-fast cancelling the matrix

[mmcky]

Summary

CI has been going red on green code. Investigating the failure on #842 (and the matching failures on recent main pushes) turned up two independent, pre-existing infra problems — neither is a real test or code failure. This PR hardens the workflow against both.

Problem 1 — Coveralls 422 race

The Coveralls step runs on all three Linux matrix jobs (if: runner.os == 'Linux') and each uploads to the same Coveralls build with no parallel coordination. Whichever Linux job reports after the build has been closed gets:

422 Can't add a job to a build that is already closed. Build … is closed.

On the #842 run, ubuntu-3.14 finished first and closed the build; ubuntu-3.13 reported a minute later → 422 → job failed. Its pytest step had already passed. This is timing-dependent and intermittent — earlier runs on the same branch were green.

Problem 2 — fail-fast cascade

The matrix had no fail-fast key, so it defaulted to true. The moment one job failed (the 422 above, or the flaky timing test below), GitHub cancelled every other in-progress job — so a single flake painted the whole 9-job matrix red, with most jobs showing cancelled rather than their real result.

Fix

Change	Effect
Upload coverage from a single Linux job (matrix.python-version == '3.13')	Only one job reports to Coveralls, so there is no build-already-closed race.
continue-on-error: true on the Coveralls step	A Coveralls outage records a warning instead of failing the job / blocking a merge.
fail-fast: false on the matrix	Jobs run to completion independently; one flaky job no longer cancels the others, and the dashboard shows each job's true result.

Coverage is unaffected in practice — this is a pure-Python library, so line coverage does not vary across OS/Python, and one uploader is sufficient.

Note: a separate flaky test (not fixed here)

While diagnosing this I found that recent main failures were caused by a different flake — a wall-clock timing assertion, quantecon/util/tests/test_timing.py::TestTimer::test_timeit_lambda_function, which overshoots on a slow runner (ACTUAL 0.207 vs DESIRED 0.05, rtol=2). With fail-fast: false that flake will no longer cancel the rest of the matrix, but the test itself can still go red on an unlucky runner. Tightening or de-timing that test is left as a follow-up so this PR stays focused on the workflow.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR hardens the GitHub Actions CI workflow by preventing flaky/non-test infrastructure failures (Coveralls upload race, and default matrix fail-fast behavior) from incorrectly turning the overall CI status red.

Changes:

• Set the test job’s matrix strategy to fail-fast: false so one failure doesn’t cancel the rest of the matrix.
• Restrict Coveralls uploads to a single Linux/Python job and mark the upload step continue-on-error: true to avoid intermittent 422/upload outages failing CI.

[coveralls]

coverage: 93.008%. remained the same — ci-harden-coveralls-failfast into main

[mmcky]

@oyamad this should fix the flaky coveralls issue we are having. I'll merge this once green but let me know if you have any issues.

[oyamad]

ChatGPT says path-to-lcov is deprecated.
It suggested the following:

      - name: Coveralls
        uses: coverallsapp/github-action@v2
        if: runner.os == 'Linux' && matrix.python-version == '3.13'
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          file: coverage.lcov
          format: lcov
          fail-on-error: false