Before submitting a whole topic or submission including parents
existed and the usage of Superproject subscriptions was low, it
was easy to predict, what would happen if a change was submitted
as it was just one change that was submitted. This is changing as
the submission process gets bigger unknowns by having coupling of
changes via their ancestors, topic submissions and superproject
subscriptions.
We would like to provide aid answering "What would happen if
I submit this change?" even more than just the submitted together
tab, as that would not show e.g. superproject subscriptions or the
underlying Git DAG. In case of merging, this also doesn't show
the exact tree afterwards.
This introduces a REST API call that will show exactly what will
happen by providing the exact Git DAG that would be produced if
a change was submitted now. Requirements for such a call:
* It has to be capable of dealing with multiple projects.
(superproject subscriptions, submitting topics across projects)
* easy to deal with on the client side, while transporting the
whole Git DAG.
This call returns a zip file that contains thin bundles which
can be pulled from to see the exact state after a hypothetical
submission.
As projects can be nested (e.g. project and project/foo), we cannot
just name the bundles as the projects as that may produce a
directory/file conflict inside the zip file. Projects have
limitations on how they can be named, which is enforced upon
project creation in the LocalDiskRepository class. One of the
rules is that no project name contains ".git/", which makes ".git"
a suffix that will guarantee no directory/file conflicts, which
is why the names are chosen to be "${projectname}.git"
In case of an error, no zip file is returned, but just a plain
message string.
We considered having a "dry run" submission process, that allows
submission of a change with a prefix to the target branch(es). As
an example:
You would call submit_with_prefix(change-id=234,
prefix=refs/testing/) which would create a branch
refs/testing/<change target branch> which is updated
to what that branch would look like. But also a
superproject would get a refs/testing/<superproject branch>
which could be inspected to what actually happened.
That has some disadvantages:
* Ref updates are expensive in Gerrit on Googles infrastructure as
ref updates are replicated across the globe. For such testing refs
we do not need a strong replication as we can reproduce them any
time.
* The ACLs are unclear for these testing branches (infer them from
the actual branches?)
* We’d need to cleanup these testing branches regularly (time to live
of e.g. 1 week?)
* Making sure the prefix is unique for all projects that are
involved before test submission
Change-Id: I3c976257c2b20de32373cbade9b99811586e926c
Signed-off-by: Stefan Beller <sbeller@google.com>
dfa1ef377d