Make BuildRoot.run() a method that bind-mounts a binary into the build
root and runs it. It has the same API as subprocess.run().
Move stage- and assembler-specific code to Stage.run() and
Assembler.run().
Compute a hash based on the content of a stage, together with the
hash of its parent stage.
The output of a pipeline is saved by the id of the last stage.
This is largely equivalent to the current logic, where it is the
pipeline that contains the id, but this means that the ids are
indepedent of how pipelines are split, the only thing that matters
is the sequence of stages, not whether or not they are in one or
several interdependent pipelines.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Rather than making the buildroot shared for a pipeline, run each
stage/assembler in a fresh one.
This avoids state to leak between the stages/assemblers.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This moves some logic from the BuildRoot and some from the Pipeline
class, into dedicated classes for stage and assembler. No functional
change.
Signed-off-by: Tom Gundersen <teg@jklm.no>
run_{stage,assembler}() take stage/assembler dicts repsectively,
expoled them in the caller and pass in each argument instead.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Only pass in the relevant array, making the type of the arguments
clearer and prepare to expoled the argumnets passed to run_{stage,assembler}.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This removes the possibility of passing in arbitrary input data. We
now restrict ourselves to explicitly specified files/directories or
a base tree given by its pipeline id.
This drops the tar/tree stages/assemblers, as the tree/untree ones
are implicit in osbuild, and if we wish to also support compressed
trees, then we should add that to osbuild core as an option.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This allows one pipline to build on top of another. When the pipeline
id of one pipeline is specified in another, the tree is initialized
with the output of the given pipeline.
The caller must ensure that the base pipeline has alreday been run,
and its content is in the content-store.
This renders the io.weldr.untree stage and the --input argument both
redundant.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Whenever an assembler is not specified, the output tree is instead
saved to the content store, in a directory named after the pipeline
id.
This should render the io.weldr.tree assembler redundant.
In order to build the samples as before, specify the content store
as the input directory to build any pipeline that uses the
io.weldr.untree stage.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This uniquely identifies a pipeline based on its content. Pipelines
are considered equal modulo whitespace and the order of object
elements.
The intention is that two runs of a pipeline with the same id
generates functionaly equivalent ids. It is up to the writers
of stages and pipelines to ensure this property holds.
Signed-off-by: Tom Gundersen <teg@jklm.no>
This follows what is done for the stages. We intend to look into
making this unnecessary, but for now allow full access so we can
work on the individual assemblers.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We need dynamic device node creation when we create loop devices
and their partitions. It would be possible to mknod them, but
just using the host /dev seems more straight-forward. Access to
the various nodes still needs to be granted explictly as we are
in the devices CGroup.
Signed-off-by: Tom Gundersen <teg@jklm.no>
We are in the devices namespace, so we must explicitly grant
permission to devices and/or device classes if we are to use
them.
We rely on being able to create and access loop devices in
order to create partitions and filesystems.
/dev/loop-control allows us to create new loop devices backed by
files. The block-loop class allows access to the created block
devices to set up a partition table and the block-blkext class
allows access to the partitions to create and mount filesystems.
Signed-off-by: Tom Gundersen <teg@jklm.no>
It's not really useful because it's at the wrong place, after a stage
has torn down all mounts. It also makes the code more complex for too
little benefit.
