a Concourse task for building OCI images
Full Changelog: https://github.com/concourse/oci-build-task/compare/v0.11.0...v0.11.1
Full Changelog: https://github.com/concourse/oci-build-task/compare/v0.10.0...v0.11.0
BUILDKIT_SECRETTEXT_*
#88IMAGE_ARG_*
where if the arg was uppercase the build would fail with an error. Image args can now be all or partially uppercaseimage_platform
which allows users to build images for platforms that don't match the current platformBumps buildkit
this release adds support for using pre-fetched images in FROM ...
! this pattern allows you to version and fetch your base image with Concourse and pass it along to the oci-build
task to use directly rather than querying the registry and fetching it at build time (possibly resolving to a different version than the build triggered with).
in your oci-build
task config, configure a IMAGE_ARG_*
param and corresponding input:
inputs:
- name: golang
params:
IMAGE_ARG_base_image: golang/image.tar
in your Dockerfile
, change the FROM
so that it can be passed as a build arg:
ARG base_image=golang
FROM ${base_image}
in your pipeline, add a resource and a get
step for fetching the image:
resources:
- name: golang
type: registry-image
source: {repository: golang}
jobs:
- name: build
plan:
- get: golang
params: {format: oci}
- task: build
# ...
this feature resolves quite a few issues:
load_base[s]
from the docker-image
resource.FROM
registry-image
resource: https://github.com/concourse/registry-image-resource/issues/240
FROM
it's kinda neat! the oci-build-task
just runs a teeny tiny Docker registry on localhost
that serves the OCI/docker image tarballs configured as image args, and then it passes addresses like localhost:45431/base_image
as build args to the Dockerfile
.
side note: if we ever do decide to switch to Kaniko (#46), the pattern will be the same; see https://github.com/concourse/docker-image-resource/issues/190#issuecomment-678524466
LABEL_*
and LABELS_FILE
, same as build argsADDITIONAL_TARGETS: target1,target2
outputs:
are also configured with names matching the targets, the target's image will be saved to the output in same way as the image
output/scratch
rather than /tmp
so buildkitd
can use the overlayfs
snapshotter
$REGISTRY_MIRRORS
(comma-separated list)--debug
to buildkitd if debug is set