chore: use ooniprobe-cli 3.11.0-beta.2 #260
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This diff changes ooniprobe-desktop to use cli v3.11.0-beta.2.
This cli release includes changes in the last (at this point six!)
months to improve measurements quality.
It is missing some extra fixes required to bless a stable
release. Chiefly among them, the possiblity of running
cleanly the DNSCheck experiment.
I'm going to work on these issues as soon as possible.
In the meanwhile, this release is a good testing base to check
whether we have additional lingering issues.
A few notes to explain this diff follows.
First, I took the liberty of reducing as much as possible
the amount of markdown linting warning I did see.
Second, 3.11.0-beta.2 is the first release that is fully built
using the cloud. I have not added any PGP key to the cloud
as this seems a bit futile. Maybe it is not and maybe I'm not
seeing the full picture, so we should discuss this topic. (I
would not put my PGP key in there, and instead I'd put another
key that has no password to sign releases; is this better
than not using any key at all?)
Third, cloud builds do not use tar.gz anymore. I did this to
work around ooni/probe#1884 (in general,
less pieces we use, less errors could occur.)
As a result, the download script needed a bit of reworking.
Fourth, while I reckon this is unlikely, I couldn't help noticing
that the previous script did not download in case files were
already on disk. To add a bit of robustness to this process, I
am now prefixing the downloaded file with its version. This way,
we'll re-download if there is a cli version change and there
are already files on disk and, by some other mistake, the build
rules are such that we don't clean existing files.
The related issue is ooni/probe#1879