We will now have a dedicated alpine based `distrobox` image. Due to
restrictions in how the `/tmp` directory in a `distrobox` image works,
it will not play nicely with generating a local tarball for rebasing a
locally built image. Going further into fixing this would required a
rootful setup and I'd rather leave the `distrobox` method as an easy way
to try out building a recipe for users who are not booted on a
`bluebuild` image.
Extra packages are installed to make the `distrobox` setup quicker and a
`distrobox.ini` file is provided to easily create the container and
export the CLI for use on the host machine. The `podman` binary is
passed into the `distrobox` container so that all images that are built
will be accessible locally and allows rootless operation without extra
setup.
This also includes a new `login` command. The signing and CI logic is now using the Driver trait system along with a new experimental sigstore signing driver. New static macros have also been created to make implementation management easier for `Command` usage and `Driver` trait implementation calls.
---------
Co-authored-by: xyny <60004820+xynydev@users.noreply.github.com>
## Stages
A new property (`stages`) is being added to the recipe file schema. This
property will allow users to define a list of Containerfile stages each
with their own modules. Stages can be used to compile programs, perform
parallel operations, and copy the results into the final image without
contaminating the final image.
### Module Support
Currently the only modules that work out-of-the-box are `copy`,
`script`, `files`, and `containerfile`. Other modules are dependent on
the programs installed on the image. In order to better support some of
our essential modules, a setup script is ran at the start of each stage
that is not `scratch`. This script will install `curl`, `wget`, `bash`,
and `grep` and use the package manager for the detected distributions.
At this time, the following distributions are supported:
- Debian
- Ubuntu
- Fedora
- Alpine
Contributions to increase the size of this list is
[welcome](https://github.com/blue-build/cli)!
### Syntax
- **Required**
- `from` - The full image ref (image name + tag). This will be set in
the `FROM` statement of the stage.
- `name` - The name of the stage. This is used when referencing the
stage when using the `from:` property in the `copy` module.
- `modules` - The list of modules to execute. The exact same syntax used
by the main recipe `modules:` property.
- **Optional**
- `shell` - Allows a user to pass in an array of strings that are passed
directly into the [`SHELL`
instruction](https://docs.docker.com/reference/dockerfile/#shell).
#### Example
```yaml
stages:
- name: ubuntu-test
from: ubuntu
modules:
- type: files
files:
- usr: /usr
- type: script
scripts:
- example.sh
snippets:
- echo "test" > /test.txt
- type: test-module
- type: containerfile
containerfiles:
- labels
snippets:
- RUN echo "This is a snippet"
```
### Tasks
- [x] `from-file:` - Allows the user to store their stages in a separate
file so it can be included in multiple recipes
- [x] `no-cache:` - This will be useful for stages that want to pull the
latest changes from a git repo and not have to rely on the base image
getting an update for the build to be triggered again.
- [x] Add setup script to be able to install necessary programs to run
`bluebuild` modules in stages
- [x] Check for circular dependencies and error out
## `copy` module
This is a 1-1 for the [`COPY`
instruction](https://docs.docker.com/reference/dockerfile/#copy). It has
the ability to copy files between stages, making this a very important
addition to complete functionality for the stages feature. Each use of
this "module" will become its own layer.
### Decision to use `--link`
We use the `--link`
[option](https://docs.docker.com/reference/dockerfile/#benefits-of-using---link)
which allows that layer to have the same hash if the files haven't
changed regardless of if the previous instructions have changed. This
allows these layers to not have to be re-downloaded on the user's
computer if the copied files haven't changed.
### Syntax
- **Required**
- `src` - The source directory/file from the repo OR when `from:` is set
the image/stage that is specified.
- `dest` - The destination directory/file inside the working image.
- **Optional**
- `from` - The stage/image to copy from.
#### Example
```yaml
modules:
- type: copy
from: ubuntu-test
src: /test.txt
dest: /
```
### Tasks
- [x] make `from:` optional
- [x] Add README.md and module.yml
## Feature gating
Gating this feature until we release for `v0.9.0`. The plan will be to
build all features (including this one) for main branch builds. This
means that these features will be available when using the `main` image
and consequently the `use_unstable_cli:` option on the GitHub Action.
All future `v0.9.0` features will be gated as well to allow for patches
to `v0.8`.
### Tasks
- [x] Build `--all-features` on non-tagged builds
- [x] Add stages and copy features
This will help make the Containerfile just a little bit easier to read
(ignoring all the mounts lol). This would also allow us to add logic
later to support modules that run executables other than `*.sh`.
I noticed that making changes to the exports script before a release
could cause modules to not build properly if breaking changes got pushed
out. To prevent this, I'm making it so that the hash of the commit is
put in the tag for the exports script image and that the CLI tool will
use that hash when building the `Containerfile`.
required for running the bluebuild CLI directly from podman (needed for
latest version of bluebuild for github action)
---------
Co-authored-by: Gerald Pinder <gmpinder@gmail.com>
Add a bug report + completions command(not complete yet) so that new
users can easily submit bugs to us, and I wanted completions for bb
(super easy with clap)
---------
Co-authored-by: Gerald Pinder <gmpinder@gmail.com>
- Builds on main and tags will use the `medium` satellite that uses `x4`
rate on build minutes
- This gives us larger cache and more memory
- Builds on PRs will use the `small` satellite that uses `x2` rate on
build minutes
- We are using the starter tier which gives us `10000` build minutes per
month and caching for our builds to make them faster
