This fix involves creating a new function for the `BuildDriver` trait
called `build_tag_push`. In order to get the proper logic in place to
make use of `docker buildx`, I had to create a separate function that
would construct the build command to include all of the tags necessary
for pushing. A default implementation of `build_tag_push` will be used
for `podman` and `buildah` which was originally from the build command's
functions. Now that we have custom logic for docker builds, we can take
advantage of using the GitHub cache features without having the `--load`
arg which had a big negative effect on build times. We can now also use
docker for creating local `oci-archive` tarballs for local rebasing.
Making use of the `oci-archive` will require the user to create a
`docker-container` builder as it is not supported on the standard
`docker` builder.
https://docs.docker.com/build/exporters/oci-docker/
https://github.com/blue-build/cli/issues/118#issuecomment-1992536977
as mentioned here reverting to the bash files module simplifies the
build process (and allows for better usage of `ostree container
commit`). It also means there are less overall layers and (ideally) a
smaller image as a result. Tested locally and template generation seems
to work just fine
the `os_version` is defaulting to the `image_tag` inside containers and
causing our template to use latest tag
---------
Co-authored-by: Gerald Pinder <gmpinder@gmail.com>
Since the command `ostree container commit` checks for the presence of
mounted directories, we will be running it at the end of each module
run. We have also updated the final commit to remove from /tmp/ and
/var/ again in case a user creates extra files through custom
instructions.
Closes#101#95
This separates out the module template logic so that it is easier to
undertstand what each section does. This will also allow creating in
repo documentation for any special modules that don't use a bash base.
An issue was filed for adding retry logic to our push_image command in
the CLI. https://github.com/blue-build/cli/issues/79.
This PR adds:
- **retry flag**
- `-r`
- defaults to true
- **retry_count flag**
- `--retry_count`
- defaults to 1
This functionality will be extended to our other services in build
(podman api as well once that is hooked up), but this is the initial
ground work
---------
Co-authored-by: Gerald Pinder <gmpinder@gmail.com>
The akmods module require having the /rpms directory put into /tmp/rpms.
By default we will mount the akmods image with the `main-{{ os_version
}}` tag.
If a user supplies `base` for the akmods module in their recipe, it will
pull that image tag instead and mount the resulting /rpms.
```yaml
modules:
- type: akmods
base: surface
install:
- openrazer
```
This would pull the image `ghcr.io/ublue-os/akmods:surface-39`.
A user can also supply `nvidia-version` with the numerical version of
the driver you would like to use. Doing so will mount the appropriate
`akmods-nvidia` image with the version of the driver you want in the
tag.
```yaml
modules:
- type: akmods
nvidia-version: 545
install:
- nvidia
```
This would pull the image `ghcr.io/ublue-os/akmods-nvidia:main-39-545`
and `ghcr.io/ublue-os/akmods:main-39`.
This uses bind mount like all the other modules so these files will not
persist into the final image.
To keep things as consistent as possible, we're switching to using the
GITHUB_TOKEN env var for login instead. Env vars were also all pulled
out into their own constants to make things more consistent.
This change also includes prioritizing public/private key signing over
OIDC keyless for GitHub for an easier transition. It would require the
user to delete their `cosign.pub` file from their repo in order to start
using the keyless method.
Trailing newlines is something that we will never need as an
information, so it can only cause issues with parsing yaml values.
I scratched my head for 10 minutes on why my variable has a trailing
newline when I use `readarray -t` everywhere. Then I remembered
get_yaml_array function.
This should not affect current working modules at all, but it would be
good to test before landing.
Co-authored-by: Gerald Pinder <gmpinder@gmail.com>
