Инструменты программиста
12.9K subscribers
1.74K photos
164 videos
4 files
2.17K links
Полезные инструменты для программистов — бесплатные и платные

Разместить рекламу: @tproger_sales_bot

Правила общения: https://tprg.ru/rules

Другие каналы: @tproger_channels

Регистрация в перечне РКН: https://tprg.ru/mX0S
Download Telegram
This media is not supported in your browser
VIEW IN TELEGRAM
Dive: почему удаление файла не уменьшило образ

Удаление файла в новом слое Docker-образа не убирает его из предыдущего слоя. В Dive можно проследить, где файл появился, менялся или был удалён. Откройте свой существующий образ:

dive <your-image-tag>


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

Dive помогает найти, где место может тратиться впустую, но сам не уменьшает образ. Его image efficiency — экспериментальная оценка, а не обещание достижимой экономии. В README инструмент отмечен как beta quality, поэтому выводы стоит проверять по составу слоёв, а не по одному проценту.
chezmoi: проверить изменения dotfiles перед применением

chezmoi хранит исходное состояние конфигурации отдельно от файлов в домашнем каталоге. Команда edit меняет управляемую копию. Изменения в домашнем каталоге нужно применять отдельно, поэтому их можно сначала просмотреть.

Если chezmoi уже установлен и инициализирован, а нужные файлы добавлены под управление, выполните:

chezmoi diff
chezmoi -n -v apply


Первая команда покажет различия, вторая подробно выведет действия без записи. Флаг -n включает dry run, -v — подробный вывод. Если изменений нет, diff может быть пустым.

Обычный apply без -n уже меняет файлы. Переходите к нему после просмотра изменений. По умолчанию исходное состояние хранится в ~/.local/share/chezmoi. На карточке — исходное состояние и команды проверки.
👍1🔥1
Проверить JSON-запрос до отправки с xh

В xh есть режим --offline: клиент собирает HTTP-запрос и выводит его в терминал, не обращаясь к серверу. Удобно, когда нужно сначала проверить типы полей в JSON и заголовки.

xh --ignore-stdin --offline POST https://example.com/users name=anna age:=24


--ignore-stdin отключает чтение тела из stdin. С name=anna в JSON попадёт строка, с age:=24 — число. Оператор == задаёт параметр query string, двоеточие — заголовок. В выводе можно проверить, куда попало каждое значение.

После проверки уберите --offline и укажите свой тестовый адрес. В этом режиме вы проверяете только состав запроса. Ответ сервера и правила валидации API он не покажет. Синтаксис похож на HTTPie, однако xh поддерживает не все его возможности и не имеет системы плагинов.
Cosign: подпись образа нужно связать с ожидаемым автором

Проверяя скачанный контейнерный образ через Cosign, заранее задайте, чью подпись вы готовы принять. В keyless-сценарии документация требует проверить и личность подписанта, и OIDC-провайдера.

За личность отвечает --certificate-identity, за провайдера — --certificate-oidc-issuer. Проверяйте оба значения: просто найти подпись у образа недостаточно, если вам нужен артефакт конкретного проекта. Ожидаемые значения берите из доверенного процесса выпуска, а не из самого непроверенного файла.

По умолчанию Cosign также сверяет digest образа с digest в подписанных данных. Это связывает подпись с конкретным содержимым. Успешная проверка подтверждает эти условия, но не подтверждает отсутствие уязвимостей в образе.
sccache и промахи кэша из-за пути к проекту

Два CI-задания собирают один код, но checkout лежит в разных абсолютных каталогах. Для sccache это существенная разница: по умолчанию абсолютные пути должны совпадать, чтобы использовать сохранённый результат компиляции.

В README описан SCCACHE_BASEDIRS. Он позволяет убрать выбранный префикс пути перед вычислением ключа кэша. В качестве базового каталога нужен абсолютный путь. Инструмент нормализует пути в исходнике после препроцессинга и подходящих аргументах компилятора, но не вырезает произвольные совпадения из любого текста.

Это настройка для повторных сборок с разными корнями checkout. Она не делает любую компиляцию кэшируемой: например, у Rust не кэшируются инкрементальные сборки и crates, вызывающие системный линкер. Проверяйте попадания и промахи по статистике sccache.
Найти тяжёлый каталог с gdu и запретить удаление

Если нужно разобраться, что занимает место в проекте, gdu покажет размеры каталогов и файлов. Для первичного осмотра можно сразу отключить удаление и получить текстовый отчёт по текущему каталогу:

gdu -n --no-delete .


Флаг -n выбирает неинтерактивный режим, --no-delete запрещает удаление. В интерактивном интерфейсе без этого ограничения есть клавиши удаления и очистки каталога, поэтому режим осмотра стоит выбрать заранее.

По умолчанию gdu считает занятое место на диске. Видимый размер содержимого файла можно посмотреть отдельно с -a. Эти величины могут различаться. Прежде чем очищать самый большой каталог, проверьте, какие данные в нём лежат.
Версии Rust для сборки и запуска nextest

cargo-nextest — отдельный запускатель тестов Cargo. Перед добавлением в CI проверьте, собираете ли вы сам nextest из исходников или используете готовую утилиту: в README для этих случаев указаны разные требования.

Минимальная версия Rust для сборки nextest — 1.91. Для запуска указан Rust 1.41, но авторы отдельно оговаривают, что столь старые версии не тестируют. Они ожидают совместимость с версиями Rust, выпущенными за последний год. Старый номер в таблице не стоит читать как гарантию для давно замороженного CI-образа.

В репозитории также есть библиотеки runner, metadata и filtering. Если вам нужен именно инструмент запуска тестов, ориентируйтесь на пакет cargo-nextest. Подробный выбор тестов и режимов вынесен в руководство проекта.