Build environment file format

design

#1

Introduction

Considering that we are decoupling knowledge from snapcraft onto an environment meant specifically to target a particular snap base, a proper format to have snapcraft request or hook into information provided by such environment necessary.

Proposal

The proposal involves mechanism to query the environment about certain attributes that target the base and others that execute as hooks so that the build environment is prepared to satisfy the needs of either snapcraft itself or one of the plugins used by snapcraft.
To allow for continuous improvements, the interaction will carry a revision to ensure snapcraft and the build environment speak the same language.

General information required

With regards of execution:

  • How to install build-packages defined in snapcraft.yaml.
    • This needs to have logic on providing what was installed with versions.
  • How to install stage-packages defined in snapcraft.yaml:
    • This needs to have logic on providing what was installed with versions.
    • A cut-off of the dependency chain related to what is provided in the base.
  • How to setup the environment so a plugin can pull, build, stage and prime correctly.

All of the above need to take into account cross compilation.

With regards to information:

  • The architecture triplet (e.g.; could be achieved through a gcc call on the build environment).

Some projects will require a certain minimum amount of memory to run, this could be specified in the build-environment on the snapcraft.yaml side.

Syntax

Given the conditions above, this shall be the proposed format:

build-environment:
    machine-requiremnts:
        minimum-ram: "2G"
    v1:  # v<format-revision>
        build-packages-handler: <command-to-exec-to-handle-build-packages>
        stage-packages-handler: <command-to-exec-to-handle-stage-packages>
        plugin-PLUGIN-setup-pull: <command-to-exec-to-handle-setup-for-plugin>
        plugin-PLUGIN-setup-build: <command-to-exec-to-handle-setup-for-plugin>
        plugin-PLUGIN-setup-stage: <command-to-exec-to-handle-setup-for-plugin>
        plugin-PLUGIN-setup-prime: <command-to-exec-to-handle-setup-for-plugin>
    v2:
        stage-packages-handler: <command-to-exec-to-handle-stage-packages>

Opens

  • should all the plugin steps be tied to one format?
  • do plugins still need to define their build environment, or should the build VM be responsible for it?

Status Tracking for Build VM
Status Tracking for Build VM
PoC on Build VM using Fedora 27