| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think that it's confusing for both strata and chunk morphologies to
have a 'chunks' field, with the former listing sources and the latter
listing rules for splitting this source into artifacts.
The design for splitting strata has roughly the same idea, but operating
on chunk artifact names, rather than file names, so a name that can be
used for both was chosen.
Splits and artifacts weren't satisfactory names, so they're now called
'products'.
It was decided to break backwards compatibility of chunk morphologies
being able to specify 'chunks', since the format has changed, so extra
code would be required to translate the format, and the only users of
the 'chunks' field was the test suite, since there was no way to select
from the system, which chunk artifacts were included.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A stratum morphology must either have stratum build-depends, or
have some bootstrap chunks, otherwise there's no way to have the
required set of commands to be able to build chunks.
A concession has been made to also allow strata that contain chunks
built in test mode, but this opens a reproducibility hole.
Unit tests for these failures have been added, and the stratum
used by other unit tests has been fixed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is better to test whether a straum is empty here, since it will be
noticed earlier in the build, as soon as the morphologies are loaded,
rather than after they have all been parsed.
It is also conceptually nicer to put it here, since the morphologyfactory
was written to perform this kind of validation.
On a more practical note, the validation is moved here so that the test
for this error isn't masked by the test for no build dependencies.
To ensure tests still pass, we alter the stratum morphology used by
other unit tests to no longer be empty, and add an empty one to test.
|
| |
|
|
|
|
|
|
|
| |
This creates a small exception hierarchy for failures to validate
stratum morphologies. This is currently a line rather than a tree,
but it will be expanded later in the patch series.
This also adds test coverage for chunk build dependencies being
omitted.
|
| | |
|
| |\
| |
| |
| | |
Reviewed-By: concensus
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\ \
| |/
| |
| |
| |
| |
| | |
Conflicts:
morphlib/bins_tests.py
Reviewed-By: consensus
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allowed values:
staging: build with a staging chroot (default)
test: build with the host's tools
bootstrap: build with the host's tools, and do not include this
chunk in the final stratum artifact
In the past, 'normal mode' has been used to describe building a chunk
with the host's tools. We don't want that mode to ever be used,
because it is a huge hole in reproducability, but we need to keep it
around to avoid making Morph's cmdtest suite depend on Baserock.
Hopefully naming it 'test' should discourage potential abusers.
It is unfortunate that the build tests now take a separate code path
compared to real-world usage of Morph. However, this is necessary to
avoid a circular dependency between Morph's test suite and the
build-essential stratum in Baserock.
We do whole-build testing of Baserock, too, so the 'staging' code path
is still tested outside of Morph. However, testing a staging area
requires populating it with at minimum a working shell, and this is a
bit too complex to go in Morph's test suite.
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
| |
Allowing differences causes only confusion. Whether or not the 'name'
field should surive at all is up for debate: it's very useful when
seeing the contents of the morphology out of context (e.g. in
documentation or pastebins), but is that worth the extra effort?
|
| |
|
|
|
|
|
|
| |
Invalid text changed to be something that doesn't parse as YAML
either, and catch convert the YAMLError to the expected exception.
Ideally there wouldn't be any `#pragma: no cover`s, but I could not
trigger these code paths.
|
| |
|
|
|
| |
armv5 and armv7 are different enough to be a problem, so specify
which particular arm sub-architecture we currently support.
|
| |
|
|
|
| |
This provides much better performance in cases where most of the
repos do not have a .morph included.
|
| |
|
|
|
|
|
| |
The cost of one git ls-tree call is roughly the same as one
git cat-file call. Therefore, when autodetecting the build system,
it is much faster to list the tree once and then search for the
required files than to call git cat-file for every possible one.
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
morphlib/morphologyfactory.py
morphlib/morphologyfactory_tests.py
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
This was done with the aid of the pep8 script, available by running
`easy_install pep8`.
It may be worth making this part of ./check, but that will require
putting pep8 into the development tools stratum.
This should be easy, given pep8 has no external dependencies.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This way we can have one place in the code where we determine what
artifacts get built from a specific morphology, rather than spreading
the information around the code base.
From now on, everything is supposed to use the builds_artifacts attribute
to get the list of artifacts. ArtifactResolver has been changed to do that.
Some of the tests are now a bit messier, and should really be changed
to create Morphology objects using MorphologyFactory, but that's a change
for another day.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Detecting the build system is managed by it asking if any files exist
detecting if the file exists is done with a callback function.
This callback can use cat-file.
If list_files existed this could be more efficient as it would not
require the files to be read from the remote server and it only needs
to be one round-trip
|
| |
|
|
|
| |
There are cases where we would not need a remote cache, so it
should be able to operate without one.
|
| |
|
