| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the build commands treat the system argument
as a path relative to the root repo.
This means that regardless of your working directory you must run
morph build systems/foo-system.morph
This behaviour can be confusing, for example when your working
directory is $systembranch/definitions/systems you might expect
to be able to run
morph build foo-system.morph
especially since most shells would tab-complete the filename for you.
At the moment running the above command from $systembranch/definitions/systems
would result in an error, because morph would look for
$systembranch/definitions/foo-system.morph rather than
$systembranch/definitions/systems/foo-system.morph
This behaviour also means you can't give the morph build commands
an absolute path to a system morph.
This patch changes the treatment of the system arg so that it is interpreted
relative to the current working directory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not everyone is a fan of the `morph build` magic that collects up your
changes and puts them in a temporary branch. Now you can disable it by
setting 'local-changes=ignore' in your morph.conf file.
This speeds up `morph build` and `morph deploy` by 5-10 seconds on my
machine.
I looked an option to make `morph build` warn if there are uncommitted
changes. I found that with a cold cache, it takes about 5 seconds on my
machine to verify that there are no uncommitted changes to a checkout of
definitions.git. That defeats the main purpose of this patch for me, so
I didn't include the option.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most usefully, this patch means that Morph no longer updates its cached
copy of definitions.git every time you run `morph build`.
Also, it prevents confusion in the following situation. Imagine I have
run:
morph checkout baserock:baserock/definitions master
I then wait a while, during which time someone pushes to 'master' in the
definitions.git repo that I cloned from. Now I run:
cd master
morph build systems/whatever.morph
Which commit does it build, the local head of 'master' or the remote
head of 'master'?
The answer, both before and after this patch, is that it builds the
local version of master. But previously, this only happened because of
the magic that we have to detect local changes. With this patch, the
local change detection could be disabled and `morph build` would still
build what the user had checked out as 'master' locally, not whatever
'master' pointed to in the remote repo.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sorry about the big lump, I can split it into a nicer set of changes,
but they didn't naturally emerge in a nice series.
This creates a pushed_build_branch context manager, to eliminate code
duplication between build and deploy.
Rather than the build branch being constructed knowing whether it needs
to push the branch, it infers that from the state of the repositories,
and whether a local build would be possible.
If there are no uncommitted changes and all local branches are pushed,
then it doesn't create temporary branches or push them, and instead uses
what it already has.
It will currently create and use temporary build branches even for
chunks that have no local changes, but it's pretty cheap, and doesn't
require re-working the build-ref injection code to check whether there
are local changes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously they were generator functions, which yielded interesting
context at interesting times so that the caller could respond by
printing status messages.
The only benefits this had over callbacks were:
1. 1 fewer function scope to worry about. I don't have data on the
amount of memory used for a function scope vs a generator, but it
could be less cognitive load for determining which variables are
defined in the callback's body.
2. It is possible to yield in the caller, so you could make that into a
coroutine too, however this wasn't required in this case, as the
yielded value was intended to be informational.
The downsides to this are:
1. It's a rather peculiar construct, so can be difficult to understand
what's going on, and the implications, which led to
2. If you call the function, but don't use the iterator it returned,
then it won't do anything, which is very confusing indeed, if you're
not used to how generator functions work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
This is useful to build releases using distbuild. It avoids having the
SHA1 fields in the artifact metadata files pointing to commits that
exist only on temporary build branches. It also avoids file:// URLs in
the repo fields. Note that the repo URL still points to the Trove used
by the distbuild network, rather than being an upstream URL pointing to
git.baserock.org.
|
| | |
|
| | |
|
| |
|
|
| |
The old build is still around for comparison.
|
| |
|
|
|
|
| |
This uses all the new APIs, so the code is shared across morphlib and
unit tested rather than everything being in one massive plugin that is
only black-box tested.
|
| | |
|
| |
|
|
|
|
|
| |
The same check that cachedir and tempdir are large enough is used
for both build and build-morphology.
Deploy only checks for tempdir being large enough.
|
| |
|
|
|
| |
Make sure all commands have one line of description, and reduce the
size of some which had large amounts of text.
|
| |
|
|
|
|
|
|
|
|
| |
This is needed because we are replacing the current build command
by a new one that builds from a local system branch. Since that will
be the more common scenario, we want the new implementaiton to go by
the name 'morph build'.
This commit therefore renames 'morph build' and updates all the
tests to use 'morph build-morphology' instead.
|
|
|
It's such a small amount of code, it's possibly not worth it,
but now all commands are in plugins.
|
