dive

English

Overview

dive is a command-line tool for inspecting Docker and OCI image layers. It presents image contents by layer and helps identify wasted space caused by how files are added, changed, or removed during image construction. The upstream project describes this as a tool for exploring a Docker image, layer contents, and ways to reduce image size. (github.com)

Purpose and typical use cases

Typical uses include:

• inspecting layer contents during image development;
• reviewing how changes in a Dockerfile affect the final image layout;
• checking for duplicated or unneeded files across layers;
• running automated image-efficiency checks in CI by using non-interactive mode.

The upstream project documents both interactive inspection and CI-oriented analysis. (github.com)

Typical users include:

• container image developers;
• CI/CD maintainers who validate image size or layer hygiene;
• build and release engineers;
• administrators who need to understand how an image is assembled.

Upstream project

Upstream project: wagoodman/dive.

The upstream repository states that dive explores Docker image layers and can be used with Docker or Podman-backed workflows. It also documents a CI mode controlled by CI=true, and notes support for Docker, Docker tar archives, and Podman as image sources. NiceOS maintainers should verify upstream behavior against the current project documentation before packaging changes. (github.com)

Dist-git repository contents

This NiceOS dist-git repository is the packaging source for the RPM package and normally contains:

• SPECS/ — RPM spec files and packaging policy;
• SOURCES/ — source metadata and manifest files used by the package;
• METADATA/ — package metadata used by the distribution tooling;
• SBOM/ — software bill of materials data when maintained for the package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/. NiceOS maintainers should treat the manifests as the authoritative repository-side record for source retrieval and verification. The exact manifest format should be checked in this repository if it changes. (github.com)

Source storage and integrity policy

NiceOS does not store large upstream release archives in dist-git. The repository keeps the packaging metadata and source manifests needed to reproduce the package sources outside Git.

Before updating the package, maintainers should verify:

• that the manifest in SOURCES/ still references the intended upstream source;
• that any source retrieval method used by the package still matches upstream distribution practice;
• that the packaging metadata does not depend on stale or renamed upstream files;
• that no local patches have become obsolete or need review.

Do not record per-release hashes, archive names, or other version-specific source details in this README.

NiceOS maintenance notes

Before updating dive, NiceOS maintainers should check:

• whether upstream documentation changed the project purpose, supported workflows, or command-line behavior;
• whether the RPM spec needs refresh for build flags, dependencies, or installation paths;
• whether any generated packaging files in SOURCES/, METADATA/, or SBOM/ need regeneration;
• whether the package still builds and runs in the expected container-image inspection workflow;
• whether CI or test automation needs adjustment after upstream changes.

Risks to consider:

• changes in upstream CLI behavior may affect scripts or CI jobs that call dive non-interactively;
• changes in image-source handling may affect local testing or packaging assumptions;
• changes in upstream release layout may require manifest or spec updates.

If any of these points are unclear from the current package state, NiceOS maintainers should verify them against upstream before submitting an update.

Build and verification checklist

For RPM maintainers, a practical update checklist is:

1. Confirm the upstream project still matches the package summary and intended use.
2. Refresh the source manifest in SOURCES/ if the upstream source reference changes.
3. Review the spec file for obsolete patches or packaging logic.
4. Rebuild the RPM in the target branch.
5. Verify that the package installs cleanly.
6. Run the package’s basic functional checks, if available.
7. Confirm that the binary starts and can inspect a local image or archive as expected.
8. Check that documentation and metadata remain consistent with upstream.

References

• Upstream repository: https://github.com/wagoodman/dive
• Upstream releases: https://github.com/wagoodman/dive/releases

Русский

Обзор

dive — это командная строка для анализа слоёв Docker- и OCI-образов. Утилита показывает содержимое образа по слоям и помогает находить лишнее место, которое возникает из-за того, как файлы добавляются, изменяются или удаляются при сборке образа. В upstream-проекте это описано как средство для просмотра слоёв Docker-образа, его содержимого и способов уменьшить размер образа. (github.com)

Назначение и типовые сценарии использования

Типовые сценарии использования:

• просмотр содержимого слоёв при разработке образа;
• анализ того, как изменения в Dockerfile влияют на итоговую структуру образа;
• поиск дублирующихся или ненужных файлов между слоями;
• автоматическая проверка эффективности образа в CI в неинтерактивном режиме.

В upstream-документации описаны как интерактивный режим, так и анализ для CI. (github.com)

Типовые пользователи:

• разработчики контейнерных образов;
• сопровождающие CI/CD, которые проверяют размер и структуру образов;
• инженеры сборки и выпуска;
• администраторы, которым нужно понимать состав образа.

Upstream-проект

Upstream-проект: wagoodman/dive.

В upstream-репозитории указано, что dive предназначен для анализа слоёв Docker-образов и может использоваться с Docker и Podman-ориентированными сценариями. Также описан CI-режим, активируемый через CI=true, и поддержка Docker, Docker tar archive и Podman как источников образа. Перед изменениями в пакете сопровождающим НАЙС.ОС следует сверять поведение с актуальной upstream-документацией. (github.com)

Содержимое dist-git репозитория

Этот dist-git репозиторий НАЙС.ОС содержит упаковочные данные для RPM-пакета и обычно включает:

• SPECS/ — spec-файлы RPM и правила упаковки;
• SOURCES/ — метаданные исходных файлов и манифесты, используемые пакетом;
• METADATA/ — метаданные пакета, используемые инструментами дистрибутива;
• SBOM/ — данные software bill of materials, если они ведутся для пакета.

Крупные upstream-архивы исходников намеренно не хранятся в этом Git-репозитории. Вместо этого контроль целостности исходников ведётся через файлы манифестов в SOURCES/. Сопровождающим НАЙС.ОС следует считать эти манифесты источником истины на стороне репозитория. Если формат манифеста изменится, его нужно отдельно проверить в этом репозитории. (github.com)

Политика хранения исходных файлов и контроля целостности

НАЙС.ОС не хранит крупные upstream-архивы релизов в dist-git. В репозитории остаются упаковочные метаданные и манифесты исходников, необходимые для воспроизведения источников вне Git.

Перед обновлением пакета сопровождающим следует проверить:

• что манифест в SOURCES/ по-прежнему указывает на нужный upstream-источник;
• что способ получения исходников соответствует текущей схеме распространения upstream;
• что упаковочные метаданные не зависят от устаревших или переименованных upstream-файлов;
• что локальные патчи не устарели и по-прежнему нужны.

В этом README не следует фиксировать хэши, имена архивов и другие изменяемые по версии детали исходников.

Замечания по сопровождению в НАЙС.ОС

Перед обновлением dive сопровождающим НАЙС.ОС следует проверить:

• не изменились ли назначение проекта, поддерживаемые сценарии или поведение командной строки в upstream-документации;
• не требуется ли обновить spec-файл из-за флагов сборки, зависимостей или путей установки;
• не нужно ли пересоздать генерируемые файлы в SOURCES/, METADATA/ или SBOM/;
• собирается ли пакет и работает ли он в ожидаемом сценарии анализа контейнерных образов;
• не требуется ли корректировка CI или тестовой автоматизации после изменений upstream.

Риски, которые стоит учитывать:

• изменения CLI могут затронуть скрипты или CI-задачи, которые запускают dive без UI;
• изменения в работе с источниками образов могут повлиять на локальные проверки или допущения упаковки;
• изменения в структуре upstream-релизов могут потребовать обновления манифестов или spec-файла.

Если какой-либо пункт не удаётся подтвердить по текущему состоянию пакета, его следует отдельно проверить по upstream перед отправкой обновления.

Контрольный список сборки и проверки

Практический чеклист для сопровождающих RPM:

1. Подтвердить, что upstream-проект по-прежнему соответствует краткому описанию пакета и его назначению.
2. Обновить манифест исходников в SOURCES/, если меняется upstream-ссылка на источник.
3. Проверить spec-файл на наличие устаревших патчей и упаковочной логики.
4. Пересобрать RPM в целевой ветке.
5. Убедиться, что пакет корректно устанавливается.
6. Выполнить базовые функциональные проверки пакета, если они предусмотрены.
7. Проверить, что бинарный файл запускается и может анализировать локальный образ или архив.
8. Убедиться, что документация и метаданные не расходятся с upstream.

Ссылки

• Upstream-репозиторий: https://github.com/wagoodman/dive
• Upstream-релизы: https://github.com/wagoodman/dive/releases

Dist-git repository notes

• Package repository: rpms/dive
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.