Document image labels

content/docs/for-buildpack-authors/how-to/write-buildpacks/add-labels.md

@@ -5,6 +5,56 @@ weight=99
 
 <!--more-->
 
-This page is a stub! The CNB project is applying to [Google Season of Docs](https://developers.google.com/season-of-docs/docs/timeline) to receive support for improving our documentation. Please check back soon.
+Labels are key-value pairs, stored as strings, that are attached to an image (i.e., arbitrary metadata). Labels are used to add helpful descriptions or attributes to an application image, which are meaningful to users.
 
-If you are familiar with this content and would like to make a contribution, please feel free to open a PR :)
+Labels are usually added at the time an image is created and can also be modified at a later time. Images can have multiple labels; however, each key must be unique.
+
+## Key Points
+
+A `LABEL`
+
+* MUST specify a unique key for a given image
+* MUST specify a value to be set in the image label  
+* MUST be added as an image label on the created image metadata
+* If one key is given multiple values, the last value overwrites  
+
+## Use Cases
+
+Since adding labels to application images is optional and not needed to run containers, this property is often overlooked. The following are few reasons to why labels should be widely adopted  
+
+* Documenting versioning
+* Record licensing information
+* Including information about a project maintainer
+* Including a description of the image and  additional metadata related to the image
+* Labels can also be used to organize images  
+
+## Implementation Steps
+
+* General syntax of `LABEL` instruction is as follows:
+
+    `LABEL <key-string>=<value-string>`
+
+    `LABEL version="1.0"`
+
+### Examples  
+
+1. A `run.Dockerfile` SHOULD set the label `io.buildpacks.rebasable` to `true` to indicate that any new run image layers are safe to rebase on top of new runtime base images
+
+    * For the final image to be rebasable, all applied Dockerfiles must set this label to `true`
+
+2. A buildpack ID, buildpack version, and at least one stack MUST be provided in the OCI image config as a Label.
+
+    Label: `io.buildpacks.buildpackage.metadata`
+
+```json
+{
+  "id": "<entrypoint buildpack ID>",
+  "version": "<entrypoint buildpack version>",
+  "stacks": [
+    {
+      "id": "<stack ID>",
+      "mixins": ["<mixin name>"]
+    }
+  ]
+}
+```

content/docs/for-buildpack-authors/how-to/write-buildpacks/use-exec.d.md

@@ -7,22 +7,24 @@ weight=99
 
 The [buildpacks `exec.d` interface](https://github.com/buildpacks/spec/blob/main/buildpack.md#execd) allows buildpack authors to execute custom scripts or binaries when the application image is started. This interface can be particularly useful for injecting dynamic behavior or environment variables into the runtime environment of an application.
 
-## Key Points:
+## Key Points
 
-    1. Location and Naming: Scripts are placed in the `<layer>/exec.d/` directory within a launch layer and must be executable. They can have any name.
+1. Location and Naming: Scripts are placed in the `<layer>/exec.d/` directory within a launch layer and must be executable. They can have any name.
 
-    2. Script Behavior:
+2. Script Behavior:
     * **Inputs**
-        * A third open file descriptor (in addition to stdout and stderr).  The third open file descriptor is inherited from the calling process.
+        *A third open file descriptor. File descriptors are integers used by a process to uniquely identify opened files; pre-opened file descriptors are usually 0 for stdin, 1 for stdout and 2 for stderr. The third open file descriptor is inherited from the calling process.  
     * **Outputs**
         * Valid TOML describing environment variables in the form of key=value pairs. These variables are added to the application's runtime environment. The content should be written to file descriptor 3 (see examples for how to do this).
         * Exit Code: The scripts should exit with a status code of `0` to indicate success. A non-zero exit code will indicate an error and prevent the application from launching.
 
-## Use Cases:
+## Use Cases
+
 * Dynamic Configuration: Inject configuration values that are determined at runtime.
 * Service Bindings: Configure environment variables based on bound services.
 
-## Implementation Steps:
+## Implementation Steps
+
 * Write Scripts: Create executable scripts within the `<layer>/exec.d/` directory.
 * Set Permissions: Ensure scripts have the appropriate execute permissions (chmod +x).
 * Environment Variables: Use scripts to print `key="value"` pairs to the third open file descriptor.
@@ -32,6 +34,7 @@ The [buildpacks `exec.d` interface](https://github.com/buildpacks/spec/blob/main
 `exec.d` executables can be written in any language.  We provide examples in bash, Go and Python that inject the `EXAMPLE="test"` into the runtime environment.  It is important that environment variables are written to the third file descriptor which is inherited by the `exec.d` binary.
 
 A `bash` example looks as follows:
+
 ```bash
 #!/bin/bash
 
@@ -43,6 +46,7 @@ echo "EXAMPLE=\"test\"" >&$FD
 ```
 
 And a `Go` example is:
+
 ```Go
 package main
 
@@ -66,7 +70,9 @@ func main() {
 	}
 }
 ```
+
 Finally, we provide a short Python example:
+
 ```Python
 import os
 import sys
@@ -82,4 +88,4 @@ if __name__ == "__main__":
     main()
 ```
 
-The `exec.d` interface provides a powerful mechanism for dynamically configuring runtime environments in a flexible and programmable manner, enhancing the customization capabilities available to application programmers using buildpacks.
+The `exec.d` interface provides a powerful mechanism for dynamically configuring runtime environments in a flexible and programmable manner, enhancing the customization capabilities available to application programmers using buildpacks.