Блог

Главная - Вопросы по программированию - Сбой cURL в действиях GitHub

Сбой cURL в действиях GitHub

#github #curl #github-actions

#github #curl #github-действия

Вопрос:

Я использую Raspberry Pi 4 в качестве сервера для моего побочного проекта .NET Core. Ничего слишком причудливого или тяжелого. После попытки начать работу с webhook и загрузки файлов с помощью scp на Pi и потерпел неудачу (до сих пор не знаю, почему на данный момент; проблема с scp может быть такой же, как и проблема cURL), я решил создать небольшой API, который принимает файл и развертывает его по указанному пути. API работает как изнутри, так и снаружи Pi, поскольку я тестировал его с помощью cURL и Postman с zip-файлом размером 20 МБ, но когда я запускаю эту команду из действия GitHub, я получаю длительное время ожидания, а затем сообщение об ошибке.

Команда:

 curl --request POST --url https://example.com/ --header 'cache-control: no-cache' --form path=DEPLOY_PATH --form archive=@FILE_PATH --form token=TOKEN

Вывод:

 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                               Dload  Upload   Total   Spent    Left  Speed
            
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
0 8776k    0     0    0 65536      0  42750  0:03:30  0:00:01  0:03:29 42722
0 8776k    0     0    0 65536      0  25862  0:05:47  0:00:02  0:05:45 25852
0 8776k    0     0    0 65536      0  18533  0:08:04  0:00:03  0:08:01 18528
0 8776k    0     0    0 65536      0  14444  0:10:22  0:00:04  0:10:18 14441
0 8776k    0     0    0 65536      0  11833  0:12:39  0:00:05  0:12:34 13091
0 8776k    0     0    0 65536      0  10022  0:14:56  0:00:06  0:14:50     0
0 8776k    0     0    0 65536      0   8691  0:17:14  0:00:07  0:17:07     0
...
0 8776k    0     0    0 65536      0     63 39:37:37  0:17:11 39:20:26     0
0 8776k    0     0    0 65536      0     63 39:37:37  0:17:11 39:20:26     0
curl: (55) SSL_write() returned SYSCALL, errno = 110
##[error]Process completed with exit code 55.

Похоже, что с командами scp и cURL существует общая проблема. Если я попытаюсь отправить простой текстовый файл или tar.gz содержащий текстовый файл, он работает. Если я попытаюсь сделать то же самое с a .dll-файл или tar.gz содержащий a .dll-файл, это не так. Я действительно не знаю, связана ли проблема с файлами или их размером. Следует отметить, что API на данный момент принимает файлы размером до 100 МБ, и я пытаюсь развернуть только небольшой пакет размером ~ 10 МБ.

Вывод с аргументом -v:

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying IP...
* TCP_NODELAY set

  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connected to URL (IP) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [112 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2861 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=URL
*  start date: Sep 18 16:51:41 2020 GMT
*  expire date: Dec 17 16:51:41 2020 GMT
*  subjectAltName: host "URL" matched cert's "URL"
*  issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
*  SSL certificate verify ok.
} [5 bytes data]
> POST /api/Deployment/ HTTP/1.1
> Host: URL
> User-Agent: curl/7.58.0
> Accept: */*
> cache-control: no-cache
> Content-Length: 3333
> Content-Type: multipart/form-data; boundary=------------------------ca1748c91973ca89
> Expect: 100-continue
> 
{ [5 bytes data]
< HTTP/1.1 100 Continue
} [5 bytes data]

100  3333    0     0  100  3333      0   2154  0:00:01  0:00:01 --:--:--  2153
100  3333    0     0  100  3333      0   1307  0:00:02  0:00:02 --:--:--  1307
100  3333    0     0  100  3333      0    938  0:00:03  0:00:03 --:--:--   938
100  3333    0     0  100  3333      0    732  0:00:04  0:00:04 --:--:--   732
100  3333    0     0  100  3333      0    600  0:00:05  0:00:05 --:--:--   614
100  3333    0     0  100  3333      0    508  0:00:06  0:00:06 --:--:--     0
100  3333    0     0  100  3333      0    441  0:00:07  0:00:07 --:--:--     0
...
100  3333    0     0  100  3333      0     57  0:00:58  0:00:57  0:00:01     0
100  3333    0     0  100  3333      0     56  0:00:59  0:00:58  0:00:01     0
100  3333    0     0  100  3333      0     55  0:01:00  0:00:59  0:00:01     0
100  3333    0     0  100  3333      0     54  0:01:01  0:01:00  0:00:01     0* Empty reply from server

100  3333    0     0  100  3333      0     54  0:01:01  0:01:00  0:00:01     0
* Connection #0 to host URL left intact
curl: (52) Empty reply from server
##[error]Process completed with exit code 52.

РЕДАКТИРОВАТЬ: переключение на Windows runner вместо Ubuntu решило проблему cURL, но я все еще открыт для предложений по этому вопросу, поскольку это всего лишь обходной путь, а не решение.