Skip to content
  • Dduvall's avatar
    build: Refactor to use BuildKit LLB library directly · 15a15584
    Dduvall authored
    Provide new `build` interfaces, `build.Target` and `build.Options`.
    
    The latter, `build.Options`, moves configuration of build-time options
    from the `buildkit` module into the core `build` module. New fields
    are introduced that were formerly handled by `dockerfile2llb`.
    
    The former, `build.Target`, provides a single interface to perform
    operations that will either affect the image config result (entrypoint,
    runtime user, etc.) or the `llb.State` graph (copy files, run commands,
    etc.).
    
    Refactor `build.Instruction` interface and implementations to accept a
    single `build.Target` argument. Instead of returning half-compiled
    Dockerfile instructions, each `build.Instruction` implementation uses
    the passed `build.Target` to add to the `llb.State` graph or make
    changes to image configuration.
    
    Note, it may be better long-term to remove the `build.Instruction`
    abstraction altogether (e.g. ostensibly we could pass the `build.Target`
    directly to `config` types), but this seems like a good interim part of
    the large refactoring as it avoided having to change anything in the
    `config` module.
    
    Refactor `buildkit` module to use the new `build.Target` and
    `build.TargetGroup` interfaces. Instead of compiling to Dockerfile and
    using `dockerfile2llb` to convert that to LLB, `build.Instruction`s are
    compiled to the `build.Target` which is marshaled directly to a
    `llb.Definition`.
    
    Provide test helper modules `llbtest` and `testtarget` to ease making
    complex assertions on the `llb.Definition` result of `build.Target`.
    
    Provide test coverage for all `build.Target` methods and refactor
    existing `build.Instruction` tests.
    
    Remove `docker` module.
    
    Bug: T345458
    Change-Id: I902faaa0a5795c38aa17816e4ea157e07211e9d6
    15a15584