two quick kinds of caching for makebuildserver
I've been running `./makebuildserver` on a machine that only connects to the internet via Tor. That means slow internet and other issues. These two small changes made it easier to run `./makebuildserver` in this setup. In combination with !25, this would give good support for working in low bandwidth environments.
See merge request !67
On some setups, using a custom apt mirror is essential, so this adds a
command line flag to override the default one:
http://ftp.uk.debian.org/debian/
For example, someone who runs a local mirror for offline and low bandwidth
situations.
This uses a % rather than a .format() to avoid escaping { and }, which have
meaning when using .format().
config.vm.box_url can be a list/tuple of URLs, which is useful to specific
a locally cached copy. This is needed on slow connections, so that if it
fails, the download of jessie32.box does not have to start from the
beginning of the file again.
Add optional support for vagrant-cachier plugin
Building the basebox is excruciating for people on slow connections. I'm particularly sensitive to this after living in Central America for awhile :)
This won't affect anyone who hasn't installed the plugin. For those who do, it creates a persistent shared folder for each box (ie. testing23.box) and detects directories to cache between VM builds (apt, gems, pip, chef cache, etc.)
(The only downside is that, for those following server setup does who are not aware what vagrant-cachier does, it might be unexpected that artifacts persist between vagrant destroys.)
See merge request !25
Two fixes
I pulled two commits out of !57 since it would be good to have them included, and specifically the `buildToolsVersion` issue was just discussed.
The current state of the `buildToolsVersion` replacement is not good. It will replace this:
```
buildToolsVersion '21.0.1'
```
with this:
```
buildToolsVersion = '21.0.1'
```
That is incorrect, since the first form is more like a function call than a variable assignment. So most likely that is causing the `buildToolsVersion` to be unset. The commit here includes a fix that works for both the rare, non-standard variable assignment way, i.e. `buildToolsVersion = '21.0.1'` as well as the standard way: `buildToolsVersion '21.0.1'`. It also includes tests for both cases.
See merge request !65
This addresses the discussion in !64https://gitlab.com/fdroid/fdroidserver/merge_requests/64
Sometimes, buildToolsVersion is a kind of gradle macro call, and other
times it is a variable assignment. This regsub pattern now handles both of
those cases.
Google code is dead and going read-only. import is just a helper program, and
we don't want to help people add apps from google code anymore. Apps should
move to other hosting sites.
Fix gradle adaptation for custom buildToolsVersion configurations
I have ```build_tools = "22.0.1"``` configured in my config.py, however a recent fdroidserver update broke this. This PR fixes it for me.
See merge request !64
final 0.4.0 fixes
Because `setup.py` is broken because `MANIFEST.in` is still pointing to `README` and not `README.md`, the 0.4.0 tag needs to be deleted. This merge requests fixes that and two other minor issues. This has passed multiple runs of the test suite, both on my machine and the jenkins box.
See merge request !61
