GitLab

Surrisingly handy and avoids much nastier approaches.

Including the file name of .cabal files within tarballs.

this will hopefully workaround a permission denied error on win32

Local .tar.gz tarball files can be listed in the 'packages:' field in
the cabal.project file. These are expected to be in the normal Cabal
source tarball format containing a single package.

We need a wrapper that takes the file by value, to cover the tarball
case. While we're at it, we report warnings on higher verbosity levels
and use proper exceptions to make error handling more consistent.

Avoid duplication in each of the helpers for fetchAndReadSourcePackages
(of which there will be several in the end).

Try the "retry N times on permission errors" strategy.

Apparently I misread the man page bit about omitting the '='.

It reports things like 'git version 2.17.1.windows.2'

Needs extra (fake) config to be supplied on the command line otherwise
it complains it doesn't know the author name or email.

Put it in the cleanup handler so it always runs, exception or not.

NB: this is only for confirming a theory

On Windows, file locks held by programs we run (in this case VCSs) are
not always released prior to completing process termination! Obviously
this is total madness since we can't know what files the child process
had locks on, and so we cannot wait for those locks to be released.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365202.aspx

This means we run into stale locks when trying to delete the test
directory. There is no sane way to wait on those locks being
released, we just have to wait and hope. Lets hope 1 second is enough.

In preparation for adding support for additional target types (local and
remote tarballs, local and remote source repos), refactor the existing
readSourcePackage action so it can be more easily extended to support
the extra target types.

In particular, having to download things means there are advantages to
handling all the packags in a batch. Indeed for source repos there will
be quite a bit of sharing, so they must be handled as a batch.

It covers all the failure modes, and currently includes one actual
network test where we fetch a git repo. There is a new testsuite feature
flag to disable network tests, and we probably want to use that in CI.

This replaces the previous Brancher abstraction. It improves the error
messages.

There is a very slight change of behaviour: previously if a package
specified multiple source repos with different types (e.g. git/darcs)
and only one of those VCS tools was installed on the system, it could
fall back to selecting the other repo using the other tool. The new
behaviour is that it picks the repo to use deterministically, and then
simply fails if the VCS program is not available. This situation is very
rare, and arguably the new behaviour is more predictable.

The standard term seems to be 'clone' rather than 'fork' for the action
of downloading a VCS repo.

This is a hopefully rather comprehensive approach: we generate an
arbitrary description of how to make a repo, and model what content we
would expect for every tag/commit. Then we can compare with executing
the description for the real VCS and comparing the actual file content
for any tag/commit.

This is then the basis for checking for the various VCS drivers that we
can (construct and) clone and sync repos properly. In particular for
syncing this gives some confidence that we can sync for any plausible
cached previous repo state.

This is intended for two things:
 * replacing the Brancher abstraction backing the current 'get -s' impl
 * the basis for source repo support in cabal.package files

The latter is a bit more complex as it requires not just fetching a
fresh repo, but syncing a repo to a specific tag, commit or branch. The
approach assumes that we keep a cached copy so that most changes are
cheap and it optimises things by allowing sharing data between multiple
commits of the same repo, and multiple packages within the same repo.

For example, it will be possible to specify the same repo in the
cabal.project file for more than one package, and have those packages
either in separate subdirs of the same commit, or on different
commits/tags/branches. In the former case we use a single checkout
while in the latter case we use two checkouts, but share repo data as
far as possible.

[ci skip]