| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: I992dc0c1d40f563ade56a833162d409b02be90a0
|
| |\
| |
| |
| |
| | |
Reviewed-By: Adam Coldrick <adam.coldrick@codethink.co.uk>
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
|
| | |
| |
| |
| |
| | |
This makes it easier to spot if an incomplete build was due to the user
cancelling, or if it represents a dropped connection or internal error.
|
| |\ \
| | |
| | |
| | |
| | | |
Reviewed-By: Javier Jardón <javier.jardon@codethink.co.uk>
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This saves a duplicate `git remote update origin` that was being run as
part of each chunk build. For any repos that have submodules, it also
avoids updating repos if the SHA1 we need to build is already present
locally.
As well as speeding up builds slightly, this means Morph can now build
without being connected to a network, as long as the local Git cache
all of the necessary repos and commits in the build, without needing the
'--no-git-update' option.
The code is also now in a more logical place than before.
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
This uses the PyLRU module, from:
<https://pypi.python.org/pypi/pylru/1.0.6>.
Python 3.2 and newer provide a built-in LRU cache, but this is
specifically for in-memory use. See <http://bugs.python.org/issue17528>.
Git commits are immutable, so caching information about their contents
is fairly easy and trouble-free. There's no danger of the cache becoming
stale.
|
| |\
| |
| |
| |
| | |
Reviewed-By: Adam Coldrick <adam.coldrick@codethink.co.uk>
Reviewed-By: Richard Maw <richard.maw@codethink.co.uk>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This consolidates a bunch of code paths that were previously duplicated.
This also changes the API for local cached repos to match the
function names GitDirectory uses. Note that the remote repo cache still
uses the old names, and should be fixed when time permits.
Some unit tests that use the CachedRepo module required a bit of
inelegant monkey-patching in order that they continue to work. A better
way to do this would be with the 'mock' library (which would need to be
added to Baserock 'build' and 'devel' systems before we could use it).
|
| |\ \
| | |
| | |
| | |
| | | |
Reviewed-By: Pedro Alvarez <pedro.alvarez@codethink.co.uk>
Reviewed-By: Richard Ipsum <richard.ipsum@codethink.co.uk>
|
| | |/ |
|
| |/
|
|
|
|
| |
Also add support to allow building compatible architectures on armv8
machines, as per the rationale in the comment in
_validate_architecture().
|
| |
|
|
|
|
|
|
| |
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)
|
| | |
|
| | |
|
