Repository navigation
Coverage testing is stopped since 1.2.2 release #5701
Description
The last report was generated on release day on the 22nd of December, and the latest was on 2nd of Dec on master. I think this probably is an issue with travis and or package versions but haven't yet looked into the details.
Reacted by P. L. Lim
Activity
pllim commentedon Jan 17, 2017
@bsipocz , I see
--coveragetest suite still runs in Travis CI. Are you talking about a separate coverage hook? That one, I cannot see, as I have no access to "Settings" here.bsipocz commentedon Jan 19, 2017
I'm talking about the coveralls reports and the feedback here about the results. Currently there are only 3 checks for a PR (travis, appveyor, circle) but it used to be there as the 4th. I don't think that it's a problem with the hook as it still works for the the maintenance and LTS branches.
pllim commentedon Jan 19, 2017
Do you know who owns the coveralls account for Astropy? @astrofrog ?
bsipocz commentedon Jan 25, 2017
I'm talking about the coveralls reports and the feedback here about the results. Currently there are only 3 checks for a PR (travis, appveyor, circle) but it used to be there as the 4th. I don't think that it's a problem with the hook as it still works for the the maintenance and LTS branches.
The last merge that got a report on coveralls was for #5171. However that was in the middle of feature freeze so the next many merges didn't actually run the travis tests and the next passing one was #5477, but that didn't generate an entry on coveralls, so something broke between those two merges.
MSeifert04 commentedon Jan 25, 2017
I changed something with coverage in #5422 and later there was also #5505. Maybe the
coveragercwas modified in an unexpected way.That's just wild guessing. :)
mhvk commentedon Jan 26, 2017
I think all those just touch what gets covered, not how this connects the results of the coverage tests to
coveralls.io.bsipocz commentedon Jan 26, 2017
I guess the easiest way to find the regression is to restart the coverage tests on travis between those two merges. Alternatively I'll try to find it by looking at the diffs.
astrofrog commentedon Jan 26, 2017
It might be worth running a build with the verbose flag on for coveralls. In fact, maybe we should always run that command in verbose mode to identify issues. What could be happening is that we have to do some hacking with the .coverage file to fix paths, and maybe this no longer works now the coverage build is in Python 3 not 2?
bsipocz commentedon Jan 27, 2017
It doesn't seem to be a py2 vs py3 issue as latest successful build was already running with python3.
astrofrog commentedon Jan 27, 2017
Did we unpin the coverage version around then in ci-helpers?
MSeifert04 commentedon Jan 27, 2017
No that happened a month earlier: astropy/ci-helpers#132
bsipocz commentedon Jan 27, 2017
@astrofrog - I don't think it's ci-helpers upstream as it's only broken for astropy core, but still works for the affiliates.
bsipocz commentedon Feb 14, 2017
It seems that #5506 broke the reports, but I don't yet see how it did it.
bsipocz commentedon Feb 15, 2017
astroplan has similar issues, and the coverage run is also using
--remote-datathere. astroplan has the coverage broken since the summer, so it's definitely not due to the recent changes of--remote-datain v1.3.pllim commentedon Feb 15, 2017
Looks like we have a winner! See #5506 (comment) and perhaps possible solution will be implemented in #5810?