This PR is paving the way for image configurations that consist of multiple files. Currently an example of such configuration is any include usage, but in the future there will be more, for instance base image that is part of https://github.com/chainguard-dev/apko/issues/806.
Example
a.apko.yaml
contents
repositories:
- foo
packages:
- bar
b.apko.yaml
include: a.apko.yaml
env:
FOO=BAR
c.apko.yaml
include: b.apko.yaml
env:
X=Y
and finally
apko_image(
config = "c.apko.yaml"
)
Details
RIght now the only file added to the build action in apko_image is the direct config. Therefore, the multi file config will fail to be evaluated by apko.
This PR introduces the apko_config rule that allows setting deps and ApkoConfigInfo provider to support transitive dependencies. We want to support including both source files and generated targets with the path referencing convention that both source and generated files are referenced as paths relative to workspace root.
Additionally I added dedicated apko_lock rule to decouple it from the one generated by apko_image. With the complex configs the restrictions in the latter were becoming problematic.
Overview
This PR is paving the way for image configurations that consist of multiple files. Currently an example of such configuration is any
include
usage, but in the future there will be more, for instancebase image
that is part of https://github.com/chainguard-dev/apko/issues/806.Example
a.apko.yaml
b.apko.yaml
c.apko.yaml
and finally
Details
RIght now the only file added to the build action in
apko_image
is the direct config. Therefore, the multi file config will fail to be evaluated by apko.This PR introduces the
apko_config
rule that allows settingdeps
andApkoConfigInfo
provider to support transitive dependencies. We want to support including both source files and generated targets with the path referencing convention that both source and generated files are referenced as paths relative to workspace root.Additionally I added dedicated
apko_lock
rule to decouple it from the one generated byapko_image
. With the complex configs the restrictions in the latter were becoming problematic.For the example above it would work as
BUILD
c.apko.yaml
The change is supposed to be fully backwards compatible - single file configs without
ApkoConfigInfo
providers are still supported.Alternative considered
Move to the Bazel based apko configs
apko_config
, which may accept the parameters for every corresponding element of apko config.How it works for example above
a.apko.yaml - remains as is
b.apko.yaml
and in
BUILD
c.apko.yaml
and in
BUILD