fix: homogeneous dib lowercase naming

Author: antoinegelloz

CONTRIBUTING.md

@@ -1,4 +1,4 @@
-# Contributing to DIB
+# Contributing to dib
 We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
 
 - Reporting a bug

README.md

@@ -1,12 +1,12 @@
-DIB: Docker Image Builder
+dib: Docker Image Builder
 =========================
 
 ![GitHub release (latest SemVer)](https://img.shields.io/github/v/release/radiofrance/dib?sort=semver)
 ![CI Status](https://img.shields.io/github/actions/workflow/status/radiofrance/dib/qa.yml?label=QA&logo=github-actions&logoColor=fff)
 [![codecov](https://codecov.io/gh/radiofrance/dib/branch/main/graph/badge.svg)](https://codecov.io/gh/radiofrance/dib)
 [![Go Report Card](https://goreportcard.com/badge/github.com/radiofrance/dib)](https://goreportcard.com/report/github.com/radiofrance/dib)
 
-DIB is a tool designed to help build multiple Docker images defined within a directory, possibly having dependencies
+dib is a tool designed to help build multiple Docker images defined within a directory, possibly having dependencies
 with one another, in a single command.
 
 ## Features
@@ -15,20 +15,20 @@ with one another, in a single command.
 - **Dependency Resolution:** Supports dependencies between images. Builds will be queued until all parent images are built, ensuring a smooth and efficient build process.
 - **Test Suites:** Run test suites on images and ensure the tests pass before promoting images to production.
 - **Build Backends:** Multiple build backends supported, including Docker/BuildKit and Kaniko. Choose the backend that best suits your needs.
-- **Execution Environments:** DIB supports multiple executors, allowing you to build images using different environments such as Shell, Docker, or Kubernetes.
+- **Execution Environments:** dib supports multiple executors, allowing you to build images using different environments such as Shell, Docker, or Kubernetes.
 
 ## Documentation
 
-To get started with DIB, please read the [documentation](https://radiofrance.github.io/dib).
+To get started with dib, please read the [documentation](https://radiofrance.github.io/dib).
 
 ## Contributing
 
-We welcome contributions from the community! If you'd like to contribute to DIB, please review our 
+We welcome contributions from the community! If you'd like to contribute to dib, please review our 
 [contribution guidelines](https://github.com/radiofrance/dib/blob/main/CONTRIBUTING.md) for more information.
 
 ## License
 
-DIB is licensed under the [CeCILL V2.1 License](https://cecill.info/licences/Licence_CeCILL_V2.1-en.txt)
+dib is licensed under the [CeCILL V2.1 License](https://cecill.info/licences/Licence_CeCILL_V2.1-en.txt)
 
 ## Support
 

cmd/list.go

@@ -14,8 +14,8 @@ import (
 // listCmd represents the output command.
 var listCmd = &cobra.Command{
 	Use:   "list",
-	Short: "Print list of images managed by DIB",
-	Long:  `dib list will print a list of all Docker images managed by DIB`,
+	Short: "Print list of images managed by dib",
+	Long:  `dib list will print a list of all Docker images managed by dib`,
 	Run: func(cmd *cobra.Command, _ []string) {
 		bindPFlagsSnakeCase(cmd.Flags())
 

docs/backends.md

@@ -1,10 +1,10 @@
 Build Backends
 ==============
 
-The build backend is a software or service responsible for actually building the images. DIB itself is not capable of
+The build backend is a software or service responsible for actually building the images. dib itself is not capable of
 building images, it delegates this part to the build backend.
 
-DIB supports multiple build backends. Currently, available backends are `docker` and `kaniko`. You can select the 
+dib supports multiple build backends. Currently, available backends are `docker` and `kaniko`. You can select the 
 backend to use with the `--backend` option.
 
 **Executor compatibility matrix**
@@ -35,7 +35,7 @@ run on the remote host instead of using the local Docker daemon.
 
 **BuildKit**
 
-If available, DIB will try to use the BuildKit engine to build images, which is faster than the default Docker
+If available, dib will try to use the BuildKit engine to build images, which is faster than the default Docker
 build engine.
 
 ## Kaniko

docs/best-practices.md

@@ -1,9 +1,9 @@
-DIB Best Practices
+dib Best Practices
 ==================
 
 ### Pin dependencies versions in Dockerfiles
 
-As DIB only rebuilds images when something changes in the build context (including the Dockerfile), external 
+As dib only rebuilds images when something changes in the build context (including the Dockerfile), external 
 dependencies should always be pinned to a specific version, so upgrading the dependency triggers a rebuild.
 
 Example:
@@ -13,5 +13,5 @@ RUN apt-get install [email protected]
 
 ### Use .dockerignore
 
-The `.dockerignore` lists file patterns that should not be included in the build context. DIB also ignores those files
+The `.dockerignore` lists file patterns that should not be included in the build context. dib also ignores those files
 when it computes the checksum, so no rebuild is triggered when they are modified.

docs/configuration.md

@@ -1,7 +1,7 @@
 Configuration
 =============
 
-DIB can be configured either by command-line flags, environment variables or configuration file.
+dib can be configured either by command-line flags, environment variables or configuration file.
 
 The command-line flags have the highest priority, then environment variables, then config file. You can set some
 default values in the configuration file, and then override with environment variables of command-line flags.
@@ -15,7 +15,7 @@ dib build --registry-url=gcr.io/project
 
 ### Environment variables
 
-DIB auto-discovers configuration from environment variables prefixed with `DIB_`, followed by the capitalized, 
+dib auto-discovers configuration from environment variables prefixed with `DIB_`, followed by the capitalized, 
 snake_cased flag name.
 
 Example:
@@ -26,7 +26,7 @@ dib build
 
 ### Configuration file
 
-DIB uses a YAML configuration file in addition to command-line arguments. It will look for a file names `.dib.yaml`
+dib uses a YAML configuration file in addition to command-line arguments. It will look for a file names `.dib.yaml`
 in the current working directory. You can change the file location by setting the `--config` (`-c`) flag.
 
 The YAML keys are equivalent to the flag names, in snake_case.

docs/documentation.md

@@ -4,7 +4,7 @@ Documentation
 The documentation is generated with [`mkdocs`](https://www.mkdocs.org/). It generates a static website in plain HTML 
 from the Markdown files present in the `docs/` directory.
 
-We also use the [Cobra](https://github.com/spf13/cobra) built-in documentation generator for DIB commands.
+We also use the [Cobra](https://github.com/spf13/cobra) built-in documentation generator for dib commands.
 
 ## Local Setup
 

docs/examples/config/reference.yaml

@@ -4,13 +4,13 @@ log_level: info
 
 # URL of the registry where the images should be stored.
 #
-# DIB will use the local docker configuration to fetch metadata about existing images. You may use the DOCKER_CONFIG
+# dib will use the local docker configuration to fetch metadata about existing images. You may use the DOCKER_CONFIG
 # environment variable to set a custom docker config path.
 # See the official Docker documentation (https://docs.docker.com/engine/reference/commandline/cli/#configuration-files).
 # The build backend must also be authenticated to have permission to push images.
 registry_url: registry.example.org
 
-# The placeholder tag DIB uses to mark which images are the reference. Defaults to "latest".
+# The placeholder tag dib uses to mark which images are the reference. Defaults to "latest".
 # Change this value if you don't want to use "latest" tags, or if images may be tagged "latest" by other sources.
 placeholder_tag: latest
 

docs/executors.md

@@ -1,7 +1,7 @@
 Executors
 =========
 
-DIB supports multiple build executors. An executor is a platform able to run image builds and tests.
+dib supports multiple build executors. An executor is a platform able to run image builds and tests.
 Unlike the build backends which can be explicitely chosen, the executor is automatically selected depending on the type 
 of operation (build, test), and the executors configured in the configuration file.
 
@@ -24,7 +24,7 @@ Runs commands in a docker container, using the `docker run` command.
 ## Kubernetes
 
 Creates pods in a kubernetes cluster, using the kubernetes API. 
-DIB uses the current kube context, please make do
+dib uses the current kube context, please make do
 
 See an example configuration in the 
 [configuration reference](configuration-reference.md) section.

docs/extra-tags.md

@@ -1,10 +1,10 @@
 Extra Tags
 ==========
 
-Images managed by DIB will get tagged with the human-readable version of the computed hash. This is not very convenient
+Images managed by dib will get tagged with the human-readable version of the computed hash. This is not very convenient
 in some cases, for instance if we want to tag an image with the explicit version of the contained software.
 
-DIB allows additional tags to be definedusing a label in the Dockerfile:
+dib allows additional tags to be definedusing a label in the Dockerfile:
 ```dockerfile
 LABEL dib.extra-tags="v1.0.0,v1.0,v1"
 ```

docs/index.md

@@ -1,13 +1,13 @@
 Introduction
 ============
 
-DIB is a tool designed to help build multiple Docker images defined within a directory, possibly having dependencies
+dib is a tool designed to help build multiple Docker images defined within a directory, possibly having dependencies
 with one another, in a single command.
 
 /// admonition | Warning
     type: warning
 
-DIB is still at an early stage, development is still ongoing and new minor releases may bring some breaking changes. 
+dib is still at an early stage, development is still ongoing and new minor releases may bring some breaking changes. 
 This may occur until we release the v1.
 ///
 
@@ -24,16 +24,16 @@ efficiency, but it's not an easy task.
 
 Also, being able to test and validate the produced images was also something that we were looking forward to.
 
-DIB was created to solve these issues, and manage a large number of images in the most efficient way as possible.
+dib was created to solve these issues, and manage a large number of images in the most efficient way as possible.
 
 ## Concepts
 
-Before using DIB, there are important basic concepts to know about, to understand how it works internally.
+Before using dib, there are important basic concepts to know about, to understand how it works internally.
 
 ### Build Directory
 
-DIB needs a path to a root directory containing all the images it should manage. The structure of this directory is not 
-important, DIB will auto-discover all the Dockerfiles within it recursively.
+dib needs a path to a root directory containing all the images it should manage. The structure of this directory is not 
+important, dib will auto-discover all the Dockerfiles within it recursively.
 
 Example with a simple directory structure:
 ```
@@ -52,12 +52,12 @@ In order to be discovered, the Dockerfile must contain the `name` label:
 LABEL name="alpine"
 ```
 
-If the `name` label is missing, the image will be ignored and DIB won't manage it.
+If the `name` label is missing, the image will be ignored and dib won't manage it.
 
 ### Dependency Graph
 
 Because some images may depend on other images (when a `FROM` statement references an image also defined within the 
-build directory), DIB internally builds a graph of dependencies (DAG). During the build process, DIB waits until all
+build directory), dib internally builds a graph of dependencies (DAG). During the build process, dib waits until all
 parent images finish to build before building the children.
 
 Example dependency graph:
@@ -69,23 +69,23 @@ graph LR
   B --> E;
 ```
 
-In this example, DIB will wait for the `alpine` image to be built before proceeding to `nodejs`, and then both
+In this example, dib will wait for the `alpine` image to be built before proceeding to `nodejs`, and then both
 `alpine` and `bullseye` can be built in parallel (see the [`--rate-limit`](cmd/dib_build.md) build option).
 
 Once `debian` is completed, the build of `bar` begins, and as soon as `nodejs` is completed, `foo` follows.
 
 ### Image Version Tag
 
-DIB only builds an image when something has changed in its build context since the last build. To track the changes,
-DIB computes a checksum of all the files in the context, and generates a human-readable tag out of it. If any file
+dib only builds an image when something has changed in its build context since the last build. To track the changes,
+dib computes a checksum of all the files in the context, and generates a human-readable tag out of it. If any file
 changes in the build context (or in the build context of any parent image), the computed human-readable tag changes as 
 well.
 
-DIB knows it needs to rebuild an image if the target tag is not present in the registry.
+dib knows it needs to rebuild an image if the target tag is not present in the registry.
 
 ### Placeholder Tag
 
-When updating images having children, DIB needs to update the tags in `FROM` statements in all child images
+When updating images having children, dib needs to update the tags in `FROM` statements in all child images
 before running the build, to match the newly computed tag. 
 
 **Example:**
@@ -122,16 +122,16 @@ Then any change to the parent image **will not** be inherited by the child.
 
 ### Tag promotion
 
-DIB always tries to build and push images when it detects some changes, by it doesn't move the reference tag 
-(`latest` by default) to the latest version. This allows DIB to run on feature branches without interfering with
-one another. Once the changes are satisfying, just re-run DIB with the `--release` flag to promote the current
+dib always tries to build and push images when it detects some changes, by it doesn't move the reference tag 
+(`latest` by default) to the latest version. This allows dib to run on feature branches without interfering with
+one another. Once the changes are satisfying, just re-run dib with the `--release` flag to promote the current
 version with the reference tag.
 
 **Example workflow**
 
-Let's assume we have a simple GitFlow setup, with CI/CD pipelines running on each commit to build docker images with DIB.
+Let's assume we have a simple GitFlow setup, with CI/CD pipelines running on each commit to build docker images with dib.
 
-When one creates a branch from the main branch, and commits some changes to an image. DIB builds and pushes the
+When one creates a branch from the main branch, and commits some changes to an image. dib builds and pushes the
 `cat-south` tag, but `latest` still references the same tag (`beacon-two`):
 
 ```mermaid
@@ -156,4 +156,4 @@ gitGraph
 
 ## License
 
-DIB is licensed under the [CeCILL V2.1 License](https://cecill.info/licences/Licence_CeCILL_V2.1-en.txt)
+dib is licensed under the [CeCILL V2.1 License](https://cecill.info/licences/Licence_CeCILL_V2.1-en.txt)

docs/install.md

@@ -15,7 +15,7 @@ Installation Guide
 
 ## Shell autocompletion
 
-Configure your shell to load DIB completions:
+Configure your shell to load dib completions:
 
 === "Bash"
 

docs/quickstart.md

@@ -1,18 +1,18 @@
 Quickstart Guide
 ================
 
-This guide will show you the basics of DIB. You will build a set of images locally using the local docker daemon.
+This guide will show you the basics of dib. You will build a set of images locally using the local docker daemon.
 
 ## Prerequisites
 
-Before using DIB, ensure you have the following dependencies installed:
+Before using dib, ensure you have the following dependencies installed:
 
 - [Docker](https://www.docker.com/) for building images on your local computer.
 - [Graphviz](https://graphviz.org/) for generating visual representation of the dependency graph (optional)
 - [Goss](https://github.com/goss-org/goss) for testing images after build (optional)
 - [Trivy](https://aquasecurity.github.io/trivy) for scanning images for vulnerabilites (optional)
 
-Then, you need to install the DIB command-line by following the [installation guide](install.md).
+Then, you need to install the dib command-line by following the [installation guide](install.md).
 
 Make sure you have authenticated access to an OCI registry, in this guide we'll assume it is `registry.example.com`.
 
@@ -36,7 +36,7 @@ FROM alpine:latest
 LABEL name="base"
 ```
 
-The "name" label is mandatory, it is used by DIB to name the current image, by appending the value of the label to the 
+The "name" label is mandatory, it is used by dib to name the current image, by appending the value of the label to the 
 registry URL. In this case, the image name is `registry.example.com/base`.
 
 Then, create the dockerfile for the `child` image, which extends the `base` image:
@@ -50,7 +50,7 @@ LABEL name="child"
 /// admonition | Tip
     type: tip
 
-The directory structure does not matter to DIB. It builds the graph of dependencies based on the FROM statements.
+The directory structure does not matter to dib. It builds the graph of dependencies based on the FROM statements.
 You can have either flat directory structure like shown above, or embed child images context directories
 in the parent context.
 ///
@@ -69,7 +69,7 @@ docker/
 └── .dib.yaml
 ```
 
-Edit the file to set the registry name, used to pull and push DIB-managed images.
+Edit the file to set the registry name, used to pull and push dib-managed images.
 ```yaml
 registry_url: registry.example.com
 ```
@@ -83,7 +83,7 @@ Using config file: docs/examples/.dib.yaml
   child  gee-minnesota-maryland-robin
 ```
 
-You should get the output containing the list of images that DIB has discovered.
+You should get the output containing the list of images that dib has discovered.
 
 ## Building the images
 
@@ -94,7 +94,7 @@ $ dib build
 ...
 ```
 
-When it's done, you can run the build command again, and you'll see that DIB does nothing as long as the Dockerfiles 
+When it's done, you can run the build command again, and you'll see that dib does nothing as long as the Dockerfiles 
 remain unchanged.
 
 When you are ready to promote the images to `latest`, run:

docs/reports.md

@@ -1,18 +1,18 @@
 Reporting
 =========
 
-DIB generates reports after each build.
+dib generates reports after each build.
 By default, the reports are generated in the `reports` directory. You can change it by setting the
 `--reports-dir` option to another location.
 
 ## HTML Report
 
 The HTML report is the one you are going to use the most.
-Just click on the link displayed on the DIB output to browse the report.
+Just click on the link displayed on the dib output to browse the report.
 
 In the report you'll find:
 
-- An overview of all images managed by DIB
+- An overview of all images managed by dib
 - The build output
 - The graph of dependencies
 - Test results and logs

docs/roadmap.md

@@ -3,7 +3,7 @@ Roadmap
 
 ## Road to v1
 
-DIB is still a work in progress, but we plan to release a stable version (v1.0.0) after we have added the 
+dib is still a work in progress, but we plan to release a stable version (v1.0.0) after we have added the 
 following features:
 
 - **Per-image configuration:** Some images may require their own tagging scheme. Being