CI does set it for us, but we don't allow env vars through to the test
scripts by default. Linux's default for XDG_CONFIG_DIR will be within
the temporary $HOME, so put the Windows one there as well.
-u makes it upgrade all apps which can be upgraded, which is a common
operation
However, we don't want device.txt to run a full install + upgrade +
uninstall cycle again, as that's too slow. For that reason, introduce an
dry-run flag in install, so that we can check that -u would do the right
thing.
Fixes#22.
This means we require Go 1.11 or later to build. Which should be fine,
as 1.12 is around the corner, and Debian only has fdroidcl in testing.
The Go version on Debian testing is already 1.11.
While at it, remove the dir funcs, as those are completely unnecessary.
This seems like a bug of some sort in fdroidserver; there's no apparent
reason why these names should contain HTML escape sequences. The name
fields are plaintext strings, so it's not like they can contain any HTML
elements.
One possible explanation is how fdroidserver obtains these strings from
the built APKs. Since the information is inside xml files, perhaps the
code is buggy and doesn't unescape the strings before using them for the
index.
For now, do the unescaping on the client side.
gitignore was keeping it off the repository, and we hadn't noticed.
The file weighs 1.6MB, but it's a great way to test with a real index
with the right size and signature. Moreover, we likely won't be updating
this file often - perhaps once every couple of years, as the index
format progresses.
Most importantly, the file is not part of any importable Go package, so
it should never find its way to a vendor folder or a module archive.
The F-Droid index format contains absolute download urls, so setting up
a custom config for the tests with the original index file won't work
when dowlnoading APKs. Those will still get downloaded from f-droid.org.
To fix that, use http.Client.Transport instead of a custom config. This
requires less code, introduces less test code in non-test files, and
means we can use the default config in the tests.
This has multiple advantages. For one, we can simplify our code, as we
can use globals like os.Stdout and flagsets directly.
It will also be easier to write parallel tests which will run faster, as
each testscript runs concurrently.
While at it, start using $HOME if set, as that is often better than
blindly relying on the current user's home directory via cgo.
Go 1.11 and 1.12 add os.UserCacheDir and os.UserHomeDir respectively, so
soon enough we'll be able to replace most of basedir with those.
Finally, stop having the tests require on the f-droid.org repository to
work. Committing under 2MB of data is plenty to get the files we need in
a static local http server, which makes the tests much faster and not
depend on an internet connection.
Follow-up commits will finish porting the rest of the tests.
This way, users can simply do:
go get mvdan.cc/fdroidcl
Instead of the repetitive:
go get mvdan.cc/fdroidcl/cmd/fdroidcl
The cmd/... pattern only makes sense if the repository has many
commands, or if the name of the repository and command don't match.
Neither is the case here.