Есть метод Brokers() у коннекта к кафке, но я не могу проверить на своем окружении

Насколько я помню - да, достаточно указать одного из них. Но это может зависеть от настроек кластера.

Подскажите пожалуйста, надо ли лочить структуру мьютексом, если идет конкуррентная запись в разные поля структуры?

запись в разные поля общего лока не требует

но, скорее всего, требует индивидуальных локов по полям

спасибо!

Хмм, прикольно

Точно требует. При наличии одновременных read + write (или write + write), будь это что угодно будет рейс.

Вы с мапом не путаете?

Ээ. Мап единственный тип, который кидает панику. Но рейс будет с любой общей переменной.

А как установить какой нибудь дефолтный хендлер, который будет обрабатывать все запросы, по урлам не описанных заранее

Нет, обращение к разным полям структуры не приведёт к рейсу

Если паралельно меняются разные поля структуры, то это обращение к разным данным, да.

нет

1) тестовые зависимости только при запуске тестов проявятся (или go get -t)
2) если ты потёр go.sum, то могло что-то пропасть из него при пересоздании

Никак не могу установить этот скитер

Сделал вот такой go.mod
https://pastebin.com/jfXSbjL6

Но теперь оно мне выдаёт вот такую ошибку. В go issues она уже есть, но я так и не разобрался что там конкретно чинить


​go: found github.com/sciter-sdk/go-sciter in github.com/sciter-sdk/go-sciter v0.0.0-00010101000000-000000000000
go: found github.com/sciter-sdk/go-sciter/window in github.com/sciter-sdk/go-sciter v0.0.0-00010101000000-000000000000
go: github.com/shumatech/go-sciter@v0.5.1-0.20200928005155-90bed320196c used for two different module paths (github.com/sciter-sdk/go-sciter and github.com/shumatech/go-sciter)

Там километровый тред и разработчики го отвечали на вопрос "Так что чинить?" что-то наподобии "зависит от того зачем вам эта replace директива"

Я бы мог конечно откатиться к 14й версии и не мучаться пока фикс не смёржат в мастер, но хотелось бы разобраться как использовать replace

Вот если что ошибка с фиксом

Всех приветствую!
Интересует мнение общества по поводу сборки проекта через docker где поставлять надо конкретно исполняемый "файл", а не в виде пуша образа в докер репозиторий.
Возник рабочий момент с двумя мнениями.
Описано немного утрировано, что-то опущено.

1 вариант. Собирать проект внутри контейнера, предварительно скопировав исходники в образ. Примерно так:

FROM golang...
...установка mingw-w64, сертификатов и тд...
COPY go.mod go.sum ./
RUN  go mod download
COPY . .
VOLUME ["/builded"]
RUN go build -o /builded/... cmd/*.go

Собирать
docker run --rm ..skip.. -v "....:/builded" myimage
Плюсы: так "принято", везде подобные примеры.
Минусы: думаю что надо регулярно чистить ненужные множащиеся образы, тк зависимости иногда меняются, а исходники всегда. В других Го проектах образы будут расти начиная с зависимостей.

2 вариант. Собирать проект снаружи, но конейнером - сборщиком. Примерно так

FROM golang...
...установка mingw-w64, сертификатов и тд...
VOLUME [ "/project" ]
VOLUME [ "/go/pkg" ]
WORKDIR /project

Собирать
docker run --rm ..skip.. -v "$(CURDIR):/project" -v "$(GOPATH)/pkg:/go/pkg" myimage go mod download && go build -o builded/... cmd/*.go
Минусы: в этом варианте возникла проблема что gitlab не может удалить созданные каталоги/файлы тк владелец их root. Победить через USER или --user и их сочетания пока не привели к успеху.
Плюсы: исходники не копируются, образ будет один и не будет меняться от сборки к сборке. В других проектах будет использоваться этот же образ.

Я склоняюсь ко второму варианту, но меня склоняют к первому :)

Поделитесь опытом. Может я что-то упустил или еще не узнал?

а почему он у тебя индирект оказался?