f8b7334662
Recipe files can now be put into their own directory `./recipes/`. This directory is NEVER copied into the build so changes to a recipe will no longer cause cache misses for builds. Here is an example of my build changing the second to last module and only requiring the last 2 `RUN` layers to be run again. ``` => CACHED [stage-config 1/1] COPY ./config /config 0.0s => CACHED [stage-modules 1/2] COPY --from=ghcr.io/blue-build/modules:latest /modules /modules 0.0s => CACHED [stage-modules 2/2] COPY ./modules /modules 0.0s => CACHED [stage-keys 1/1] COPY cosign.pub /keys/jp-desktop-gaming.pub 0.0s => CACHED [stage-4 2/16] RUN --mount=type=bind,from=stage-keys,src=/keys,dst=/tmp/keys mkdir -p /usr/etc/pki/containers/ && cp /tmp/keys/* /usr/et 0.0s => CACHED [stage-bins 1/3] COPY --from=gcr.io/projectsigstore/cosign /ko-app/cosign /bins/cosign 0.0s => CACHED [stage-bins 2/3] COPY --from=docker.io/mikefarah/yq /usr/bin/yq /bins/yq 0.0s => CACHED [stage-bins 3/3] COPY --from=ghcr.io/blue-build/cli:main-installer /out/bluebuild /bins/bluebuild 0.0s => CACHED [stage-4 3/16] RUN --mount=type=bind,from=stage-bins,src=/bins,dst=/tmp/bins mkdir -p /usr/bin/ && cp /tmp/bins/* /usr/bin/ && ostree 0.0s => CACHED [stage-4 4/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => CACHED [stage-4 5/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => CACHED [stage-4 6/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => CACHED [stage-4 7/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => CACHED [stage-4 8/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => CACHED [stage-4 9/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => CACHED [stage-4 10/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => CACHED [stage-4 11/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => CACHED [stage-4 12/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => CACHED [stage-4 13/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => CACHED [stage-4 14/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind 0.0s => [stage-4 15/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind,from= 33.4s => [stage-4 16/16] RUN --mount=type=tmpfs,target=/var --mount=type=bind,from=stage-config,src=/config,dst=/tmp/config,rw --mount=type=bind,from=s 0.7s ``` Support was also added to put all build files into `./files/` instead of `./config/`. This is an all or nothing operation, meaning if there exists a directory of `files` then the `config` directory will be completely ignored. Work will have to be done in https://github.com/blue-build/modules to allow users to put their files directly in `./files/` and not `./files/files` for the `files` module or `./files/scripts` for the scripts module. Support was also added to move the `./config/containerfiles/` directory to the root of the project. Now the directories you can find in the root of projects are: ``` files/ containerfiles/ recipes/ ```
76 lines
3.1 KiB
Markdown
76 lines
3.1 KiB
Markdown
# `containerfile`
|
|
|
|
:::caution
|
|
Only compiler-based builds can use this module as it is built-in to the BlueBuild CLI tool.
|
|
:::
|
|
|
|
The `containerfile` module is a tool for adding custom [`Containerfile`](https://github.com/containers/common/blob/main/docs/Containerfile.5.md) instructions for custom image builds. This is useful when you wish to use some feature directly available in a `Containerfile`, but not in a bash module, such as copying from other OCI images with `COPY --from`.
|
|
|
|
Since standard compiler-based BlueBuild image builds generate a `Containerfile` from your recipe, there is no need to manage it yourself. However, we know that we also have technical users that would like to have the ability to customize their `Containerfile`. This is where the `containerfile` module comes into play.
|
|
|
|
## Usage
|
|
|
|
### `snippets:`
|
|
|
|
The `snippets` property is the easiest to use when you just need to insert a few custom lines to the `Containerfile`. Each entry under the `snippets` property will be directly inserted into your final `Containerfile` for your build.
|
|
|
|
```yaml
|
|
modules:
|
|
- type: containerfile
|
|
snippets:
|
|
- COPY --from=docker.io/mikefarah/yq /usr/bin/yq /usr/bin/yq
|
|
```
|
|
|
|
This makes it really easy to copy a file or program from another image.
|
|
|
|
:::note
|
|
**NOTE:** Each entry of a snippet will be its own layer in the final `Containerfile`.
|
|
:::
|
|
|
|
### `containerfiles:`
|
|
|
|
The `containerfiles` property allows you to tell the compiler which directory contains a `Containerfile` in `./containerfiles/`.
|
|
|
|
Below is an example of how a `containerfile` module would be used with the `containerfiles` property:
|
|
|
|
```yaml
|
|
modules:
|
|
- type: containerfile
|
|
containerfiles:
|
|
- example
|
|
- subroutine
|
|
```
|
|
|
|
In the example above, the compiler would look for these files:
|
|
|
|
- `./containerfiles/example/Containerfile`
|
|
- `./containerfiles/subroutine/Containerfile`
|
|
|
|
You could then store files related to say the `subroutine` `Containerfile` in `./containerfiles/subroutine/` to keep it organized and portable for other recipes to use.
|
|
|
|
:::note
|
|
**NOTE:** The instructions you add in your `Containerfile`'s each become a layer unlike other modules which are typically run as a single `RUN` command, thus creating only one layer.
|
|
:::
|
|
|
|
### Order of operations
|
|
|
|
The order of operations is important in a `Containerfile`. There's a very simple set of rules for the order in this module:
|
|
|
|
- For each defined `containerfile` module:
|
|
- First all `containerfiles:` are added to the main `Containerfile` in the order they are defined
|
|
- Then all `snippets` are added to the main `Containerfile` in the order they are defined
|
|
|
|
If you wanted to have some `snippets` run before any `containerfiles` have, you will want to put them in their own module definition before the entry for `containerfiles`. For example:
|
|
|
|
```yaml
|
|
modules:
|
|
- type: containerfile
|
|
snippets:
|
|
- COPY --from=docker.io/mikefarah/yq /usr/bin/yq /usr/bin/yq
|
|
- type: containerfile
|
|
containerfiles:
|
|
- example
|
|
- subroutine
|
|
```
|
|
|
|
In the example above, the `COPY` from the `snippets` will always come before the `containerfiles` "example" and "subroutine".
|