| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
This code is an essential part of 'morph build'. It's quite complex and
really shouldn't be mixed in with the base Application class.
Given a dedicated class we can store some state in the object and avoid
functions with seven parameters, too.
|
|
|
|
|
|
|
|
|
|
|
| |
The recent changes to the BuildCommand.build() function caused distbuild
to break, because I didn't make the same change to the
InitiatorBuildCommand.build() function but did change how it was called.
This commit adds the ability to have optional fields in distbuild
messages. This is used to add an optional 'original_ref' field, which
will get passed to `morph serialise-artifact` by new distbuild
controllers, and will be ignored by older ones.
|
|
|
|
|
| |
This means that we can force the building of a specific commit without
losing the original branch name in the metadata of the resulting system.
|
|
|
|
|
|
|
|
|
| |
Rather than take a list of triplets to build, the BuildCommand.build()
function now takes a single repo/ref/morph triplet. Iterating through
multiple sets of triplets is now done in the build plugin.
There are a couple of cosmetic changes to the status output at the start
and end of a build as a result.
|
| |
|
|
|
|
|
|
|
| |
There's no need because all strata live in the same Git repository now.
This message was added back when there could be multiple versions of
strata coming from different repos or different refs in the same repo
and life was very confusing.
|
|\
| |
| |
| |
| | |
Reviewed-by: Pedro Alvarez
Reviewed-by: Richard Maw
|
| | |
|
|/
|
|
|
|
|
|
| |
This patch started off as an attempt to address the comment in
find_root_artifacts, though this patch doesn't impose an ordering on the list
of artifacts as the comment suggested. The artifact resolver now returns
a list of root artifacts which may make it easier to add multi-system builds
to morph.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Building per-artifact results in undesirable behaviour,
as multiple artifacts are produced for every chunk build.
It therefore makes more sense to build per-source.
This implies that actually, the model of one source per
morphology is wrong and we should move the dependencies
into the source.
Unlike chunks however, where every chunk artifact has the
same dependencies, stratum artifacts can have different
dependencies.
So before we can move the dependencies into the Source,
we need to have as many Sources as Stratum Artifacts.
|
|
|
|
|
| |
There's other methods called get_sources in other modules, and
fetch_sources explains more about what it does in the context.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It will now load the morphology from the definitions repository if the
"morph" field is present in the chunk spec.
Rather than adapting the loop to fit yet-more changing circumstances, it
has been partially rewritten, so there is one loop for loading
systems and strata from definitions.git, another for chunks from
definitions.git, and a third for chunks in the source repository.
This is tidier than attempting to fit the logic in the main loop, as it
makes it easier to remove afterwards when we no longer need to load
chunk morphologies from the source repository.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than repeatedly stripping and appending an optional .morph extension
morphology names, instead always use the file path of the morphology
relative to the definitions repository.
This is an inversion of the previous logic, which would strip the .morph
extension and use the "name" internally.
The exception to this rule of always using the filename, is that `morph
edit CHUNK` uses the name of the morphology as-defined in the stratum.
This is based off Adam Coldrick's inital patch, but this version will
allow the old style of providing the "name" by converting it into a path
if it does not have either a / or a . in it.
An unfortunate consequence of this change is that the show-dependencies
command's output changed, so the test needed updating.
|
|
|
|
|
|
| |
After a failed attempt to connect to the controller node
the initiator will wait 30 seconds before attempting a reconnect,
if this reconnect fails the initiator gives up.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Artifacts can have multiple parts; while this may not be an ideal
design, changing the format of artifacts has implications for backwards
compatibility.
We should transfer all parts at once and delete them all if we encounter
any errors, to reduce the change of getting the local artifact cache
into an inconsistent state.
|
|
|
|
|
|
|
|
|
|
|
| |
Previously Morph would check if an artifact is present in the remote
artifact cache, then fetch the necessary files. If an error occured
during fetching, it would raise an error and abort.
Instead, we should just try and fetch the files and if anything fails,
move on to building locally. This avoids the situation where an error in
the remote cache makes local building impossible, which we experienced
recently.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
morphlib/plugins/deploy_plugin.py
without-test-modules
Reviewed by:
Richard Maw
Lars Wirzenius
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
| |
Make the message "Installing chunk..." be chatty, i.e., only displayed
when the user turns verbosity higher. Most of the time the chunk is
already unpacked in the cache, so installing it takes a fraction of
a second.
Add a new message, at default verbosity, when a chunk needs to be
unpacked. This can take a while, so a message is appropriate, so the
user knows what is happening.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When you attempt to build a stratum or chunk, the ArtifactResolver can
return multiple root artifacts, since the root source produces multiple
artifacts.
Rather than having the BuildCommand complain that there's multiple root
artifacts, it now validates all the produced artifacts too, since that
will validate the kinds of artifacts produced, and give a more useful
error message, that you're trying to build a stratum or chunk directly.
If all the produced artifacts validate, then an exception is raised to
signal that it got multiple artifacts, when it only expected one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bootstrap chunks don't make it into the final system, so there needs to
be an extra check for empty systems after the sources have been collected.
This was complicated slightly by the fact that if you try to build a chunk
directly you will have no strata in your sources, hence no non-bootstrap
chunks, but validation for having been told to build a chunk is best
handled later.
This amends the old yarns that depended on building a bootstrap chunk
and adds a new one that explicitly builds a system with bootstrap
chunks.
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
Changed the message according to suggestion by Rob Kendrick,
supported by Daniel Silverstone.
|
|/ |
|
| |
|
|
|
|
|
| |
This also removes the long-obsolete code to install staging fillers
in the staging area. We've not allowed users to do that for ages now.
|
|
|
|
|
|
|
|
|
| |
This uses the same logic as when a build fails, so it's been
consolidated into `StagingArea.abort()`.
You could argue that if a build fails before any commands are run,
then there's nothing interesting to see, but it will be useful if the
hardlink/tarball extract algorithm fails in some corner case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cross-bootstrap is a way to build baserock on an architecture that
does not currently have Baserock. It can be used by `morph
cross-bootstrap <ARCH> <REPO> <REF> <MORPH>`, and will build an artifact
that can be used as a root filesystem with a basic build environment
with a script named `native-bootstrap` which will build and install
every chunk in the system.
If done with a devel system, this will give you a suitable environment
for building a proper Baserock system.
This does not currently provide a kernel for the target architecture.
Apart from adding the cross-bootstrap plugin, it also makes the
following changes:
* Moves the lit of valid_archs into morphlib (instead of locally-scoped
in MorphologyFactory)
* BuildCommand takes an extra argument, build_env
* split BuildCommand's get_artifact_object into create_source_pool and
resolve_artifacts (plus changes things that use get_artifact_object to
use the new way)
* setup_mounts finds out whether to do so by whether build_mode is
'staging', instead of by whether the setting 'staging-chroot' is true.
* Makes ChunkBuilder's get_sources use the
morphlib.builder2.extract_sources() method, and moved
set_mtime_recursively into morphlib.builder2, since it's not currently
used anywhere else.
* moved ChunkBuilder's get_commands into the Morphology class (plus
changes to anything that used get_commands)
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This puts the information in the status prefix, so it appears
every time status() is used.
This also required the places where the name was manually spliced in
to be removed.
|
|
|
|
|
| |
I find it easier to read without them, since there are less variables
to remember.
|
|
|
|
|
|
| |
Now, inside the temporary directory we will have the following
subdirectories: chunks, staging, failed and deployments. The failed
directory will contain the staging areas of failed builds.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Define a specific set of 4 architectures that Morph supports, and only
expose that value to morphologies.
Since GNU triplets are very common we also expose a GNU triplet. Other
morphologies should work out their configuration based on MORPH_ARCH.
This commit also removes the morphlib.util.arch() function, which
detected the machine Morph is running on via 'uname -m'. Morph's
architecture names do not necessarily map to the output of 'uname -m'
so we should not rely on it anywhere.
|
|
|
|
|
| |
We can no longer build strata individually because we don't know
what architecture they are for.
|
|
|
|
|
|
|
| |
This gives us some forward compatibility leeway to introduce new
build modes, as long as they are compatible with staging.
As suggested by Richard Maw.
|
|
|
|
|
|
|
|
|
|
|
| |
When building a stratum artifact it's easy to only include chunks that
were built in 'staging' mode. Constructing the staging area doesn't use
that code path, though, so we need an extra hack to filter out those
artifacts while building.
It may be neater to express stratum build-depends as actual
dependencies on the stratum artifact, rather than each of its
constituent chunks as we do now.
|