feat: Look for recipes in ./recipes/, build files in ./files/, and Containerfiles in ./containerfiles/ (#157 )

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/
```

2024-04-13 19:08:31 +00:00

3.1 KiB

Raw Blame History

`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 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.

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:

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:

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".

3.1 KiB Raw Blame History

containerfile