| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
- All tests now pass
- The odd case of chunks with the same name but different repo URLs now
correctly informs the user of the multiple checkouts that were done.
- Tidyups
|
| |
|
|
|
| |
uname tends to only give us a valid morph architecture on x86_64,
this makes it work on other architectures.
|
| |
|
|
| |
My fault for failing to commit the .stdout file when I updated the test.
|
| | |
|
| |
|
|
|
| |
It should be fixed and re-enabled by someone who understands what's
going on in the test. Preferably by writing it into yarn form.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces a new requirement: USERS MUST NOT HAVE SENSITIVE
DATA IN THEIR ENVIRONMENT. Otherwise it will be leaked into the system.
Note that configuration fields with 'PASSWORD' in their name are
stripped before writing the /baserock/deployment.meta file, so the
OpenStack OS_PASSWORD field is not leaked.
We want this so that we can run hooks at upgrade-time in the future.
These hooks might need to know how the system was configured and what
releaseuu it was. I'm not quite sure how we will define 'release' yet,
but by using `git tag` and `git describe` we are able to textually label
a time period in the history of the system's source code. We already
have the specific SHA1 of definitions.git stored in the system metadata,
so this should give us enough to be able to implement specific hooks
that work around any awkward upgrade complications we encounter in the
future.
|
| |
|
|
|
| |
Refs should be completely omitted, and this is now the standard
behaviour, so there's little value in testing the behaviour separately.
|
| | |
|
| |\
| |
| |
| |
| | |
Reviewed by Lars Wirzenius
Reviewd by Richard Ipsum
|
| | | |
|
| |\ \
| | |
| | |
| | | |
Changed the error (exception) to list all obsolete fields.
|
| | |/ |
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
From now on, `morph deploy` will work to only accept a cluster
morphology as argument. A cluster morphology defines a list of
systems to built, and for each system a list of ways to deploy
them. We will not support the old syntax anymore.
- Update `morph deploy` docstring with the new syntax, including
an explanation of cluster morphologies (also document `tar`
deployments).
- Fix tests that used the old syntax.
- Add tests for cluster deployments.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
That means that bootstrapping Baserock is currently not possible with
this branch of Morph, but there's no reason it cannot be bootstrapped
using an older version of Morph instead.
|
| |
|
|
|
| |
Also, make test use bash instead of sh, so it passes on squeeze
as well as Baserock.
|
| |
|
