Hi, recently I've been seeing a lot of Scrutinizer failures such as[0].
It fails at stage
Waiting for External Code Coverage
With error message:
The code coverage data was not received within the specified time. Please make sure your third-party service is configured to send code coverage data.
And additional information:
Code coverage data is not yet available. Code Coverage was not sent to Scrutinizer. Make sure that you have set-up your external service correctly. You can find more information on this in the documentation:
https://scrutinizer-ci.com/docs/tools/external-code-coverage/If you need help you can also email support@scrutinizer-ci.com.
Does anyone have any idea about this? I couldn't really find any information about this particular message online.
0 - https://scrutinizer-ci.com/g/phpmyadmin/phpmyadmin/inspections/1a2ea9a8-fcf9...
Le sam. 30 mai 2015 à 13:44, Isaac Bennetch bennetch@gmail.com a écrit :
Hi, recently I've been seeing a lot of Scrutinizer failures such as[0].
It fails at stage
Waiting for External Code Coverage
With error message:
The code coverage data was not received within the specified time. Please make sure your third-party service is configured to send code coverage data.
And additional information:
Code coverage data is not yet available. Code Coverage was not sent to Scrutinizer. Make sure that you have set-up your external service correctly. You can find more information on this in the documentation:
https://scrutinizer-ci.com/docs/tools/external-code-coverage/If you need help you can also email support@scrutinizer-ci.com.
Does anyone have any idea about this? I couldn't really find any information about this particular message online.
0 -
https://scrutinizer-ci.com/g/phpmyadmin/phpmyadmin/inspections/1a2ea9a8-fcf9...
Hi,
It seems that there are a serie of failures, then a serie of success and a serie of failures again, etc. If I'm right, the code coverage should be sent by Travis. Isn't it possible that Travis has some rushs some times, so it takes too much time to run the code coverage and send it in less than one hour ? I'm not sure this is a pMA issue, but it might be a provider issue…
Hugues.
On Sun, May 31, 2015 at 2:14 AM, Hugues Peccatte hugues.peccatte@gmail.com wrote:
Le sam. 30 mai 2015 à 13:44, Isaac Bennetch bennetch@gmail.com a écrit :
Hi, recently I've been seeing a lot of Scrutinizer failures such as[0].
It fails at stage
Waiting for External Code Coverage
With error message:
The code coverage data was not received within the specified time. Please make sure your third-party service is configured to send code coverage data.
And additional information:
Code coverage data is not yet available. Code Coverage was not sent to Scrutinizer. Make sure that you have set-up your external service correctly. You can find more information on this in the documentation:
https://scrutinizer-ci.com/docs/tools/external-code-coverage/If you need help you can also email support@scrutinizer-ci.com.
Does anyone have any idea about this? I couldn't really find any information about this particular message online.
0 -
https://scrutinizer-ci.com/g/phpmyadmin/phpmyadmin/inspections/1a2ea9a8-fcf9...
Hi,
It seems that there are a serie of failures, then a serie of success and a serie of failures again, etc. If I'm right, the code coverage should be sent by Travis. Isn't it possible that Travis has some rushs some times, so it takes too much time to run the code coverage and send it in less than one hour ?
It can happen when too many builds get queued in Travis and the respective builds are running in scrutinizer. So scrutinizer keeps waiting and times out because code coverage report will not be available because travis build hasn't started yet due to high load [1].
As this is happening more often, I've remove code coverage from Scrutinizer. So, it now does not expect any code coverage from Travis nor Travis will send one.
[1]: https://github.com/scrutinizer-ci/scrutinizer/issues/109
I'm not sure this is a pMA issue, but it might be a provider issue…
Hugues.
Hi
Dne Sat, 30 May 2015 07:43:54 -0400 Isaac Bennetch bennetch@gmail.com napsal(a):
Hi, recently I've been seeing a lot of Scrutinizer failures such as[0].
Does anyone have any idea about this? I couldn't really find any information about this particular message online.
0 - https://scrutinizer-ci.com/g/phpmyadmin/phpmyadmin/inspections/1a2ea9a8-fcf9...
For this the Travis build failed and thus did not send coverage information. I don't see why as after_script on Travis should be executed even in case of build failure...
Anyway I think it makes sense to remove coverage from Scrutinizer, it makes the setup just more complex with no big benefits.
-
Chirayu Chiripal -
Hugues Peccatte -
Isaac Bennetch -
Michal Čihař