Appveyor builds intermittently fail while uploading artifacts #2993

Closed
opened 2019-03-11 13:39:42 +00:00 by exarkun · 2 comments

For example, https://ci.appveyor.com/project/tahoe-lafs/tahoe-lafs/builds/22978547/job/6uw22y64rcam277g has a failed job with a log that ends:

Uploading artifacts...
[1/47] dist\appdirs-1.4.3-py2.py3-none-any.whl (12,154 bytes)...100%
[2/47] dist\argparse-1.4.0-py2.py3-none-any.whl (23,000 bytes)...100%
[3/47] dist\asn1crypto-0.24.0-py2.py3-none-any.whl (101,571 bytes)...100%
[4/47] dist\attrs-19.1.0-py2.py3-none-any.whl (35,784 bytes)...100%
[5/47] dist\autobahn-19.2.1-py2.py3-none-any.whl (302,987 bytes)...100%
[6/47] dist\Automat-0.7.0-py2.py3-none-any.whl (37,638 bytes)...100%
[7/47] dist\boltons-19.1.0-py2.py3-none-any.whl (163,903 bytes)...100%
[8/47] dist\cffi-1.12.2-cp27-cp27m-win32.whl (157,191 bytes)...100%
[9/47] dist\characteristic-14.3.0-py2.py3-none-any.whl (15,045 bytes)...100%
[10/47] dist\Click-7.0-py2.py3-none-any.whl (81,299 bytes)...100%
[11/47] dist\constantly-15.1.0-py2.py3-none-any.whl (7,922 bytes)...100%
[12/47] dist\cryptography-2.6.1-cp27-cp27m-win32.whl (1,253,393 bytes)...100%
[13/47] dist\eliot-1.6.0-py2.py3-none-any.whl (104,922 bytes)...100%
[14/47] dist\enum34-1.1.6-py2-none-any.whl (12,427 bytes)...100%
[15/47] dist\foolscap-0.13.1-py2-none-any.whl (315,007 bytes)...100%
[16/47] dist\hkdf-0.0.3-cp27-none-any.whl (3,773 bytes)...100%
[17/47] dist\humanize-0.5.1-cp27-none-any.whl (17,929 bytes)...100%
[18/47] dist\hyperlink-18.0.0-py2.py3-none-any.whl (37,905 bytes)...100%
[19/47] dist\idna-2.8-py2.py3-none-any.whl (58,594 bytes)...100%
[20/47] dist\incremental-17.5.0-py2.py3-none-any.whl (16,667 bytes)...100%
[21/47] dist\ipaddress-1.0.22-py2.py3-none-any.whl (18,155 bytes)...100%
[22/47] dist\magic_wormhole-0.11.2-py2.py3-none-any.whl (130,626 bytes)...100%
[23/47] dist\Nevow-0.14.4-py2-none-any.whl (449,148 bytes)...100%
[24/47] dist\pyasn1-0.4.5-py2.py3-none-any.whl (73,683 bytes)...100%
[25/47] dist\pyasn1_modules-0.2.4-py2.py3-none-any.whl (66,953 bytes)...100%
[26/47] dist\pycparser-2.19-py2.py3-none-any.whl (111,078 bytes)...100%
[27/47] dist\pycryptopp-0.7.1.869544967005693312591928092448767568728501330214-cp27-cp27m-win32.whl (1,473,748 bytes)...100%
[28/47] dist\PyHamcrest-1.9.0-py2.py3-none-any.whl (52,311 bytes)...100%
[29/47] dist\PyNaCl-1.3.0-cp27-cp27m-win32.whl (181,405 bytes)...100%
[30/47] dist\pyOpenSSL-19.0.0-py2.py3-none-any.whl (53,333 bytes)...100%
[31/47] dist\pypiwin32-223-cp27-none-any.whl (1,028 bytes)...100%
[32/47] dist\pyrsistent-0.14.11-cp27-cp27m-win32.whl (54,835 bytes)...100%
[33/47] dist\pyutil-3.1.0-cp27-none-any.whl (393,647 bytes)...100%
[34/47] dist\pywin32-224-cp27-cp27m-win32.whl (6,836,723 bytes)...
Error uploading artifact the storage: Unable to read data from the transport connection: The connection was closed.

It's not clear we can fix the actual problem ourselves as this seems to be part of Appveyor-implemented functionality. Perhaps we could avoid that functionality entirely in favor of something we control and can make work reliably. Or perhaps we can report this issue to Appveyor and get them to make it reliable.

A mitigating step might be to upload fewer artifacts from Appveyor. I'm not sure why we upload all of those third-party wheels. Are we hoping they will be helpful to someone? Seems unlikely. It seems like just uploading the Tahoe-LAFS wheel would be sufficient. But, for that matter, do we need to make a Tahoe-LAFS Windows wheel? Shouldn't a cross-platform wheel be possible?

For example, <https://ci.appveyor.com/project/tahoe-lafs/tahoe-lafs/builds/22978547/job/6uw22y64rcam277g> has a failed job with a log that ends: ``` Uploading artifacts... [1/47] dist\appdirs-1.4.3-py2.py3-none-any.whl (12,154 bytes)...100% [2/47] dist\argparse-1.4.0-py2.py3-none-any.whl (23,000 bytes)...100% [3/47] dist\asn1crypto-0.24.0-py2.py3-none-any.whl (101,571 bytes)...100% [4/47] dist\attrs-19.1.0-py2.py3-none-any.whl (35,784 bytes)...100% [5/47] dist\autobahn-19.2.1-py2.py3-none-any.whl (302,987 bytes)...100% [6/47] dist\Automat-0.7.0-py2.py3-none-any.whl (37,638 bytes)...100% [7/47] dist\boltons-19.1.0-py2.py3-none-any.whl (163,903 bytes)...100% [8/47] dist\cffi-1.12.2-cp27-cp27m-win32.whl (157,191 bytes)...100% [9/47] dist\characteristic-14.3.0-py2.py3-none-any.whl (15,045 bytes)...100% [10/47] dist\Click-7.0-py2.py3-none-any.whl (81,299 bytes)...100% [11/47] dist\constantly-15.1.0-py2.py3-none-any.whl (7,922 bytes)...100% [12/47] dist\cryptography-2.6.1-cp27-cp27m-win32.whl (1,253,393 bytes)...100% [13/47] dist\eliot-1.6.0-py2.py3-none-any.whl (104,922 bytes)...100% [14/47] dist\enum34-1.1.6-py2-none-any.whl (12,427 bytes)...100% [15/47] dist\foolscap-0.13.1-py2-none-any.whl (315,007 bytes)...100% [16/47] dist\hkdf-0.0.3-cp27-none-any.whl (3,773 bytes)...100% [17/47] dist\humanize-0.5.1-cp27-none-any.whl (17,929 bytes)...100% [18/47] dist\hyperlink-18.0.0-py2.py3-none-any.whl (37,905 bytes)...100% [19/47] dist\idna-2.8-py2.py3-none-any.whl (58,594 bytes)...100% [20/47] dist\incremental-17.5.0-py2.py3-none-any.whl (16,667 bytes)...100% [21/47] dist\ipaddress-1.0.22-py2.py3-none-any.whl (18,155 bytes)...100% [22/47] dist\magic_wormhole-0.11.2-py2.py3-none-any.whl (130,626 bytes)...100% [23/47] dist\Nevow-0.14.4-py2-none-any.whl (449,148 bytes)...100% [24/47] dist\pyasn1-0.4.5-py2.py3-none-any.whl (73,683 bytes)...100% [25/47] dist\pyasn1_modules-0.2.4-py2.py3-none-any.whl (66,953 bytes)...100% [26/47] dist\pycparser-2.19-py2.py3-none-any.whl (111,078 bytes)...100% [27/47] dist\pycryptopp-0.7.1.869544967005693312591928092448767568728501330214-cp27-cp27m-win32.whl (1,473,748 bytes)...100% [28/47] dist\PyHamcrest-1.9.0-py2.py3-none-any.whl (52,311 bytes)...100% [29/47] dist\PyNaCl-1.3.0-cp27-cp27m-win32.whl (181,405 bytes)...100% [30/47] dist\pyOpenSSL-19.0.0-py2.py3-none-any.whl (53,333 bytes)...100% [31/47] dist\pypiwin32-223-cp27-none-any.whl (1,028 bytes)...100% [32/47] dist\pyrsistent-0.14.11-cp27-cp27m-win32.whl (54,835 bytes)...100% [33/47] dist\pyutil-3.1.0-cp27-none-any.whl (393,647 bytes)...100% [34/47] dist\pywin32-224-cp27-cp27m-win32.whl (6,836,723 bytes)... Error uploading artifact the storage: Unable to read data from the transport connection: The connection was closed. ``` It's not clear we can fix the actual problem ourselves as this seems to be part of Appveyor-implemented functionality. Perhaps we could avoid that functionality entirely in favor of something we control and can make work reliably. Or perhaps we can report this issue to Appveyor and get them to make it reliable. A mitigating step might be to upload fewer artifacts from Appveyor. I'm not sure why we upload all of those third-party wheels. Are we hoping they will be helpful to someone? Seems unlikely. It seems like just uploading the Tahoe-LAFS wheel would be sufficient. But, for that matter, do we need to make a Tahoe-LAFS Windows wheel? Shouldn't a cross-platform wheel be possible?
exarkun added the
unknown
normal
defect
1.12.1
labels 2019-03-11 13:39:42 +00:00
exarkun added this to the undecided milestone 2019-03-11 13:39:42 +00:00
Author

Maybe we should use GitHub actions instead of Appveyor. I hear it's the new hotness that everybody loves.

Maybe we should use [GitHub](wiki/GitHub) actions instead of Appveyor. I hear it's the new hotness that everybody loves.
Author

We did indeed move to GitHub Actions and stopped using Appveyor.

We did indeed move to [GitHub](wiki/GitHub) Actions and stopped using Appveyor.
exarkun added the
wontfix
label 2020-08-27 14:36:32 +00:00
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Reference: tahoe-lafs/trac-2024-07-25#2993
No description provided.