After all the refactoring done so far, we can run checks directly
inside of `make`, because we have auto-cleanup, temporary environments
and we don't need wrapper scripts anymore.
Part of https://github.com/ooni/probe/issues/1466.
Part of https://github.com/ooni/probe/issues/1440.
Basically, let us continue to update our build infrastructure so that we can release v3.10.0-beta.
Now, it's the turn of iOS.
The main changes here are two. First, tweak some bits of the POM template
to make sure it's current, including referencing the correct repo. (We were
still referencing probe-engine in there, weirdly enough).
Second, change the android build script to create the same bundle that
mavan would build. What remains to do is uploading manually.
(Because it seems my PGP key is required, I guess this development rules
out automatically generating releases at GitHub. We will see about it
later on and possibly zap the publish-android.sh script.)
Reference issue: https://github.com/ooni/probe/issues/1437.
The release 2021.04.07-180801 has been created by me using this
diff from the v3.9.0 tag. I will update the release notes as soon
as this new release becomes available from Maven Central.
* doc: ensure all top dirs have an explanatory README
This makes the repository a lil bit nicer to newcomers.
Part of https://github.com/ooni/probe/issues/1335
* fix: re-run bindata to embed the README
The readme is small, so we can pay the price of adding it.
On a related note, I am very pleased the Go team implemented the
`//go:embed` feature, so we can get rid of this bindata thing.
* refactor: start building an Android package
Part of https://github.com/ooni/probe/issues/1335.
This seems also a good moment to move some packages out of the
engine, e.g., oonimkall. This package, for example, is a consumer
of the engine, so it makes sense it's not _inside_ it.
* fix: committed some stuff I didn't need to commit
* fix: oonimkall needs to be public to build
The side effect is that we will probably need to bump the major
version number every time we change one of these APIs.
(We can also of course choose to violate the basic guidelines of Go
software, but I believe this is bad form.)
I have no problem in bumping the major quite frequently and in
any case this monorepo solution is convinving me more than continuing
to keep a split between engine and cli. The need to embed assets to
make the probe more reliable trumps the negative effects of having to
~frequently bump major because we expose a public API.
* fix: let's not forget about libooniffi
Honestly, I don't know what to do with this library. I added it
to provide a drop in replacement for MK but I have no idea whether
it's used and useful. I would not feel comfortable exposing it,
unlike oonimkall, since we're not using it.
It may be that the right thing to do here is just to delete the
package and reduce the amount of code we're maintaining?
* woops, we're still missing the publish android script
* fix(publish-android.bash): add proper API key
* ouch fix another place where the name changed
