This patch series includes some required cleanups.
Checkout and Branch share code now.
The RepoAliasResolver should be a little quicker.
The RepoAliasResolver can now give aliases from URLs.
branch-from-image is untested where the root repository
you specify on the command line is different to the one
the image was built from.
It does not work with images built without pushing, since
they have local repository paths.
Some branch and merge cleanups were possible, but the petrify
command still uses a different code path to tag.
Richard Maw (8):
Make metadata include the repo-alias.
Add a regression test for metadata including repo alias
repoaliasresolver: compile patterns on creation
RepoAliasResolver: Add aliases_from_url method
Make petrify more versatile than just making tags
branch and merge: combine checkout and branch logic
branch and merge: add branch-from-image command
Add a black-box test for branch-from-image
morphlib/builder2.py | 1 +
morphlib/builder2_tests.py | 3 +-
morphlib/plugins/branch_and_merge_plugin.py | 206 +++++++++++++++------
morphlib/repoaliasresolver.py | 75 ++++++--
morphlib/repoaliasresolver_tests.py | 48 +++++-
tests.as-root/branch-from-image-works.script | 57 ++++++
tests.as-root/branch-from-image-works.setup | 1 +
tests.as-root/branch-from-image-works.stdout | 1 +
tests.as-root/metadata-includes-repo-alias.script | 49 +++++
tests.as-root/metadata-includes-repo-alias.setup | 48 +++++
10 files changed, 413 insertions(+), 76 deletions(-)
create mode 100755 tests.as-root/branch-from-image-works.script
create mode 120000 tests.as-root/branch-from-image-works.setup
create mode 100644 tests.as-root/branch-from-image-works.stdout
create mode 100755 tests.as-root/metadata-includes-repo-alias.script
create mode 100755 tests.as-root/metadata-includes-repo-alias.setup
Just dropping a note on Maui Os - http://www.maui-project.org
Looks like these guys have some similar aims wrt to updates and
application handling. Might be worth checking out and possibly
I will look deeper into this when I get a chance.
Rob Taylor, CTO, Codethink Ltd.
Office: +44 161 236 5575
Cell: +44 7891 533856
* repo: git://git.baserock.org/baserock/baserock/morph
* branch: liw/soft-pyyaml-dep
* commit: e06eafcbf0784271f51c0936852d1e97c0ccce8b
This makes Morph work even when the yaml library is not available.
The test suite passes, by virtue of parts of it being skipped, and the
modified Morph can build the base system. Obviously morphologies that
use YAML won't work, but we aren't using them yet, and shouldn't, until
there's been a Baserock release with the new Morph.
Lars Wirzenius (1):
Make yaml be an optional dependency
check | 9 +-
morphlib/__init__.py | 14 ++++
morphlib/morph2.py | 2 +-
morphlib/morph2_tests.py | 34 ++++----
morphlib/morphologyfactory.py | 3 +-
morphlib/yamlparse.py | 185 ++++++++++++++++++++++-------------------
morphlib/yamlparse_tests.py | 15 ++--
7 files changed, 151 insertions(+), 111 deletions(-)
This will fix bootstrap, which is currently failing due to missing
Sam Thursfield (1):
Disable distcc by default
morphlib/app.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
The basic behaviour of given an image, create a System Branch petrified
at the point where it was built is well specified, but I still have some
further questions about how it should work before I get too tied to an
implementation which may turn out to be wrong.
1. How should the baserock metadata be given.
a. Path to Disk image
branch-from-image mounts it to find the metadata.
b. Path to directory
branch-from-image globs for metadata in the directory
c. List of paths to metadata files
branch-from-image leaves finding metadata up to caller
2. How is this testable.
I was thinking build a system, move the system artifact somewhere,
delete the cache and check whether the system artifact produced has
the same cache key.
3. Does the caller specify the branch's root repository and name?
The branch the System was built from and its repository is stored
in the metadata, but if it doesn't exist any more, it will need a
Specifying gives it a nice symmetry with `morph branch` which
defaults to branching from master, but can be told a different
branch instead. With it given you're saying branch as this but from
this image instead of master.
4. Should it fail to create the branch if it already exists in the
workspace, or treat it like a petrify?
5. When should it give up trying to make the branch?
a. When the commit the System was built from does not exist?
b. When the branch the System was built from does not have a similar
This could be expensive to work out and probably not worth the
c. When the branch does not exist at all?
At this point the morphologies can be regenerated from the
metadata, but it's going to be complicated.
This series of patch provides a tool that reads a rootfs artifact to
find out the chunks that were used to create it, and generates a manifest
of: artifact name, version number (if correctly guessed), commit,
repository, ref, morphology.
Jannis Pohlmann (17):
Move MountableImage class into morphlib
Make all messages in MountableImage chatty
Add ExtractedTarball class and method to extract/mount an artifact
Add image analysis plugin
Add a 'morph content-manifest' command to the image analysis plugin
Also list the original refs in "morph content-manifest"
Rename image analysis plugin to image inspection plugin
Rename artifact inspection plugin to image inspection plugin
Squashme: Add artifact_inspection_plugin.py to without-test-modules
Get rid of tabs in the content manifest output
Squashme: Small spacing adjustments
Add version guessing for autotools projects
Add configure.in to the AutotoolsVersionGuesser
Add support for reading manifest meta data from /baserock
Add labels to the manifest output fields
Avoid unnecessary spaces in the manifest outpu
Add support for the old syntax of AM_INIT_AUTOMAKE
morphlib/__init__.py | 2 +
morphlib/bins.py | 27 ++
morphlib/extractedtarball.py | 61 +++++
morphlib/mountableimage.py | 81 ++++++
morphlib/plugins/artifact_inspection_plugin.py | 294 +++++++++++++++++++++
morphlib/plugins/trebuchet_plugin.py | 58 +---
.../run-in-artifact-propagates-exit-code.exit | 1 +
.../run-in-artifact-propagates-exit-code.script | 33 +++
.../run-in-artifact-propagates-exit-code.stderr | 3 +
...run-in-artifact-with-different-artifacts.script | 47 ++++
...run-in-artifact-with-different-artifacts.stderr | 1 +
...run-in-artifact-with-different-artifacts.stdout | 12 +
without-test-modules | 4 +
13 files changed, 568 insertions(+), 56 deletions(-)
create mode 100644 morphlib/extractedtarball.py
create mode 100644 morphlib/mountableimage.py
create mode 100644 morphlib/plugins/artifact_inspection_plugin.py
create mode 100644 tests.as-root/run-in-artifact-propagates-exit-code.exit
create mode 100755 tests.as-root/run-in-artifact-propagates-exit-code.script
create mode 100644 tests.as-root/run-in-artifact-propagates-exit-code.stderr
create mode 100755 tests.as-root/run-in-artifact-with-different-artifacts.script
create mode 100644 tests.as-root/run-in-artifact-with-different-artifacts.stderr
create mode 100644 tests.as-root/run-in-artifact-with-different-artifacts.stdout
tl;dr: is it OK if some of Morph's black box tests only work when
run on a Baserock devel system, and require build-essential
artifacts to be present in the artifact cache?
Earlier we discussed the testing strategy for the next stage of the work
I'm doing, which is to make Morph always build in a staging chroot and
to provide the staging filler automatically, by compiling the
build-essential stratum with the host's tools. We agreed some simple
tests that can go in our temporary Jenkins instance.
After the meeting I realised I have another problem. Morph has a bunch
of tests that build simple chunks in various ways using the host's
tools. These work in the "normal" build mode, which uses the host's
tools instead of a staging area. Ideally, I want to get rid of "normal"
build mode except for when build-essential is being rebuilt, but this
leaves the build tests at sea without a paddle. I see the following options:
- change them to require use of a staging area, and therefore use tools
from build-essential instead of the host's tools. This will mean that
these tests can only be run on a working Baserock devel system which can
provide a built build-essential stratum.
- change them to use the host-tools mode that we'll use for the first
stage of building build-essential itself. I worry that this will be
quite ugly, but it would probably work well enough.
- keep 'normal' mode in Morph just for the tests. This means that we are
testing a code path that is only used for tests, which seems quite silly.
Does anyone have opinions on this? Officially we only support Morph on
Baserock and on Debian Squeeze already and the Squeeze support will no
longer be needed once we have the new bootstrap mechanism in place, so
this change wouldn't be as drastic as it might sound.
Dear Baserock users,
The changes I described in my original patch mails have now been
merged to master.
The changes are quite drastic and currently cause some regressions, so
I'll quickly summarise them here:
- 'foundation' and 'devel' no longer exist. Baserock now consists of
the following strata:
- build-essential: the minimum set of tools that can rebuild
itself (from tarballs)
- core: the remaining set of components necessary to produce
a Baserock system which can rebuild itself from source
- tools: auxiliary development tools and libraries
- bsp: device-specific chunks
- the following chunks are now built from tarballs instead of from git:
autoconf, binutils, busybox, ccache, eglibc, flex, gawk, gcc,
gdbm, gettext, libtool, linux, m4, make, pkg-config
- the -base system is much larger (around 700MB) and includes lots of
unnecessary stuff. This is a known regression which will be fixed
when proper stratum splitting is implemented in Morph.
Users who are building real-world systems should stick with the stable
water-bomb release for the time being.
Feel free to respond to this mail with any further questions, but please
read the initial patch mails first to see if your question was answered
This makes morph able to know its own version from git.
`morph --version` now outputs the output of `git describe` at the time
it was built, or of the checkout it is run from.
The morphology metadata also includes this information, plus the ref,
commit and tree it was built from.
Richard Maw (3):
Make morph get its version from git.
Include morph-version in artifact metadata
Add regression test for metadata including version
morphlib/__init__.py | 5 +-
morphlib/builder2.py | 7 +++
morphlib/gitversion.py | 57 ++++++++++++++++++++
setup.py | 53 ++++++++++++++++--
.../metadata-includes-morph-version.script | 52 ++++++++++++++++++
.../metadata-includes-morph-version.setup | 48 ++++++++++++++++
without-test-modules | 1 +
7 files changed, 216 insertions(+), 7 deletions(-)
create mode 100644 morphlib/gitversion.py
create mode 100755 tests.as-root/metadata-includes-morph-version.script
create mode 100755 tests.as-root/metadata-includes-morph-version.setup