Блог

У меня есть проект, использующий go mod и CGO имеющий относительно большое дерево зависимостей.

Сборка изначально ( GOOS=linux , GOARCH=amd64 ) работает нормально. Сборка в CI (на моем собственном бегуне) с использованием моего пользовательского контейнера сборки (включая несколько архитектур arm ) работает в основном нормально, хотя иногда я получаю «зависания» при go get настройке deps.

Использование того же образа сборки для локальной сборки arm (мне нужно использовать контейнер из-за CGO и соответствующую архезависимую C-toolchain) теперь выдает мне следующие ошибки (один пример из многих):

 go: downloading github.com/go-co-op/gocron v1.9.0
scheduler/scheduler.go:7:2: github.com/go-co-op/gocron@v1.9.0: Get "https://goproxy.io/github.com/go-co-op/gocron/@v/v1.9.0.zip": net/http: TLS handshake timeout
 

Однако я вижу (с btop ), что незадолго до этой ошибки qemu-arm был очень занят (800% процессора) выполнением go связанных задач сборки (фактически go mod tidy процесса).

Я предполагаю, что это связано с тем, что не найден подходящий двоичный arm файл для определенных модулей, поэтому он просто будет создавать их на лету.

Поэтому я подозреваю, что время для сборки соответствующего модуля из исходного кода считается go get как обычный «go get from http», что приводит к наблюдаемому таймауту.

Следовательно, это означало бы, что я мог бы решить проблему, если бы я мог увеличить значение таймаута для go get , но я не нашел никакой информации об этом.

Есть идеи?

У вашего интернет-провайдера могут быть ограничения на доступ https://goproxy.io адрес. Вы должны использовать прокси

установите прокси-сервер в терминале следующим образом:

 export https_proxy=127.0.0.1:1080