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
This keeps memory usage low because it only has to read a chunk at a time
into memory while before it read the whole file into memory before
uploading it.
This also seems to handle setting the permissions ACL better.
For devs that want to build and distribute nightly builds of their apps
using the fdroid tools. The core idea here is to make the fdroidserver
tool suite the single set of tools for all types of builds and releases.
That will hopefully drive more free software developers to make f-droid.org
an core channel for official releases.
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