| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: I992dc0c1d40f563ade56a833162d409b02be90a0
|
| |
|
|
| |
Change-Id: I771c3de9cecda7a503f4d36ae5d9fabc040892e4
|
| |
|
|
|
| |
Previously, if no repos were found Morph would raise 'ValueError: need
more than 0 values to unpack' and leave the user with a traceback.
|
| |
|
|
|
|
|
|
|
|
| |
When running 'morph build' the code looks through all the Git repos in
a system branch, to see which are involved in the build. These are then
checked for local changes and have temporary build refs created in them.
Due to a mistake in the logic, this would give up if it found a repo
that came from elsewhere but was inside the system branch directory. So
in the past some legitimate repos might have been ignored sometimes.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 using `git ls-remote` every time to see if there are changes
at the remote end, use a local cache.
Git already solves this problem with its refs/remotes/$foo branch
namespace, so we can just use that instead.
In addition, the detection of which upstream branch to use has been
improved; it now uses git's notion of which the upstream branch of your
current branch is, which saves effort in the implementation, and allows
the name of the local branch to differ from that of the remote branch.
This now won't notice if the branch you currently have checked out had
commits pushed from another source, but for some use-cases this is
preferable, as the result equivalent to if you had built before the
other push.
It may make sense to further extend this logic to check that the local
branch is not ahead of the remote branch, instead of requiring them to
be equal.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A semantic error in the BuildBranch class meant that it was not possible
to push temporary branches.
This escaped testing since BuildBranch interacts too tightly with
other components to be easily unit-tested, so testing was deferred to
a yarn test.
However, coverage isn't measured in yarn tests, so this code path was
forgotten.
|
| | |
|
|
|
This is an abstraction on top of SystemBranchDirectories, providing the
ability to add uncommitted changes to the temporary build branch, push
temporary build branches and retrieve the correct repository URI and ref
to build the system.
|
