| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
It is entirely possible that we could accidentally give chunks that use
morphologies from the definitions repository, the definitions repository
to build from, rather than the source repository.
|
| |
|
|
|
|
|
|
| |
We don't use this in definitions.git, and we're going to change its
semantics, so the test suite would break until we introduced the new
semantics, unless we remove its use of the old semantics first.
|
|
|
|
|
|
| |
This is required to ensure the right version of morph is used. I have
a .bashrc that causes `morph` to be "$HOME/morph/morph", so it fails to
find morph, because HOME is set to a directory inside DATADIR.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to move our morphologies in our definitions repository into
subdirectories, so they're more organised.
We'd prefer to only refer to morphologies by file path, rather than a
name that loosely corresponds to the file path, but we need to support
that for backwards compatibility until we can move all of our
morphologies into the definitions repository.
However, since we want to eventually remove this, and we want to ensure
that file paths work, we change the yarn tests to use file paths.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`morph merge` only worked for a small subset of cases, and has been left
to bit-rot, since we don't use it.
`morph tag` is just a `git tag` when we have petrified definitions
repository. We don't use it, nor do we need it, so it can go away rather
than take up valuable development time fixing it when requirements
change.
`old-foo` have all been superceded by newer versions and are no-longer
used.
|
| |
|
|\
| |
| |
| | |
Reviewed-by: Sam Thursfield and Richard Ipsum
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
It should no longer be possible to set these fields. Either we create
the morphologies with them in a GIVEN, at which point we already know
it's there, so checking whether it is there is pointless; or we check
that morph doesn't create them, but the current implementation would not
allow it, since yarn doesn't have THEN NOT.
|
|
|
|
|
| |
Refs should be completely omitted, and this is now the standard
behaviour, so there's little value in testing the behaviour separately.
|
| |
|
| |
|
|
|
|
|
|
| |
This moves the GIVEN system $system uses $artifacts from $source to the
generic implements section, and the Python implementation into the
edit-morph helper script.
|
| |
|
|
|
|
|
|
|
| |
This includes tests for systems with the default splits and a system
that selects only one of the produced stratum artifacts to go into the
system artifact, since this is roughly the expected use-case for the
tiny system morphologies.
|
| |
|
|
|
|
|
|
|
| |
It's useful for the splitting tests that will be implemented later, for
there to be files that are representative of the files that would be on
a common root filesystem, so the match rules can be tested by the right
chunk artifacts containing the right files.
|
|
|
|
|
| |
morph build the system... doesn't need the repository to be specified,
just the branch; morph is able to work it out for itself.
|
| |
|
|
|
|
|
|
| |
It doesn't make sense to be able to specify an architecture from the
IMPLEMENTS name, since you either need your architecture for something
to build, or testarch for something that consistently doesn't build.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
It doesn't currently make sense to build a system which contains no
strata. We may later add other fields, such as initramfs to contribute
to the system's artifact, but until then it's another bug to trip over.
This uses collections.Sequence for checking the type of the systems entry
in the morphology as a style choice, though it allows more flexibility
if the types in the parsed morphology change.
|
| |
|
|
|
|
| |
argument
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This will allow the user to append text to /etc/fstab during a
deployment, without having to write custom configuration extensions.
|
| |
|
|\
| |
| |
| |
| | |
Reviewed-by: Lars Wirzenius
Reviewed-by: Richard Maw
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 2dc382a2a9ae977b1158002cd2631ec5593959c1, reversing
changes made to 89a019af088ff62459699a6efdadf8ac8fe35dd9.
We decided to restore the old commands for the release, as we weren't
confident the new implementations were correct yet.
To gain that confidence we need to use them, so the old versions are no
longer available, and the new edit code is used when the edit subcommand
is invoked.
Doing so also requires the test suite to use the edit command instead of
new-edit.
|
|
|
|
|
|
|
| |
The test suite got adapted so it requires the new edit instead of the
old one. So use the new edit instead of the old one in the test.
This is a kluge, and needs to be reverted after the BR10 release.
|
| |
|
|
|
|
|
|
| |
The MorphologyLoader validates morphologies stricter than old code, so
adjust the test morphology accordingly: add arch to a system morphology,
and build-mode and build-depends to a stratum one.
|
| |
|
|
|
|
|
|
|
|
|
| |
Checkout needs the branch repository and ref. It was previously only
getting the ref.
This was not noticed, since the implementation was only used in
cases where it was expected to fail, and the nature of the error
was not being checked.
|
|
These scenarios test the basics of most of the subcommands the
branch and merge plugin provides. They don't purport to be complete,
but give some indication that things work, and form a basis upon
which further things can be built. Yarn also isn't included in a
Baserock release yet, so we need to keep the cmdtests until Baserock
10 has been released.
The existing cmdtest tests are not modified by this: they are left
intact, until they can analysed in detail for things to be added to
the scenarios. After that, the cmdtest tests will start to go away.
Merging is not covered by these tests: it is not clear how merge should
work, and the current code is known to do the wrong thing in many cases.
Scenarios for merge will be added later.
Building is also not covered. Testing builds well needs some additional,
careful thinking, and that isn't ready for this patch series. It will
be added later.
|